shiftJIS

Haha, I guess everybody is as confused as me.Actually, the habit is coming from C, where you have to type all of your variables and functions. I'm actually not all that specific about typing in php, but my current project will be offered to the public eye, so I've been trying to take all steps into making it clean and legible to others.I suppose my confusion starts at the php docs: As you notice, they describe all the functions and tell you 1) the type the function returns, and 2) the types it takes as arguments.I do know that we don't have to declare types of variables, but I wanted to - I suppose what I wanted was for the functions I declared to throw an error if it was sent the wrong type (that is, without having to rely on the error catching code).Also, in the IDE that I use, functions you declare get added to the autocomplete list. My neurotic side wanted the little description to include those types.Anyhow, I suppose I'll leave it be for now and just stick with what works. Thanks for everybody's input!--UpdateGrr, If I only knew what to look for in the docs. Seems the answer was right there:http://us3.php.net/manual/en/language.oop5.typehinting.phpQuote from the little text at the bottom:

That doesn't answer my question. I'm not worried about what happens after the function is called, I'm confused as to why calling the function using the syntax $this->some_method("some string") doesn't pass it a string.

So, here's a watered down snippet of what I've been working on: class SOMETHING{ public $TEXT; public function some_method(string $var){ $this->TEXT = $var; } public function __construct(){ $this->some_method("default"); }} This has an error "Fatal error: Argument 1 passed to SOMETHING::some_method() must be an object of class string, called in.."So, the thing is, if I changed that function some_method to some_method($var), it'd work as intended. But the results aren't what I expected them to be. Doesn't calling the function with ("default") pass a string?Any ideas what's up?

The #nav div doesn't need to be first. The float will set it where it needs to be regardless. And actually, some people prefer the navigation to come after the content as it'll show up that way in text browsers. Where you put it is up to you.

The issue is that both your .menu and .content divs are absolutely positioned. It's a bit of in issue if you cannot guarantee that the content will be longer than the menu div. I've been thinking about this problem a lot, and my method is to float the menu and div. Since you're using a fixed-width layout, just float those two divs, and put in a <div style="clear: both; height: 1px; margin-bottom: -1px"> </div> before the footer. The "clear:both" is what will push the footer below all other floated content, and you could very well just apply it to the footer. I personally prefer having a spacer div there.

It doesn't do anything because you deleted the starting <form> tag.

foreach is used to parse through elements of an array.Thus, it's expecting $_POST['radio'] to be an array. It then cycles though each element of that array, setting the value of the element to $value. I'm assuming you're deleting multiple messages (I mean, that count is there), so you need that foreach. I'd go look at your html and make sure that the form is returning an array into 'radio'.

If you add a float:left on your #nav div then it should be where you want it.

Again, it can be done with CSS as I've shown on my test page. I'm sure you've just made some oversight on the part of your CSS style.

What CSS did you try?I set up a few boxes:http://kashi.freelancedreams.com/textarea.htmlYou can use the readonly attribute, and either set the border color to match your background, or just set it to border: none; Either should be fine. I tested it with firefox 2.0, IE7, Opera9, SeaMonkey. Style doesn't work right on the PSP or sidekick though >_<;

First of all, I'm assuming that you're taking data out of a <textarea> tag and directly inserting that data into <pre> tags. If that's not the case, you'll need to explain a little more (source code would be ideal).The pre tag is for text where you want the whitespace and line breaks to show up. The issue here - I'm assuming you're seeing lines wrap when you type in the textarea. The thing is, these line wraps AREN'T line breaks. The <pre> treats it as one long line and it renders as such.It's better to use a textarea field again in the preview. Set the attribute disabled="disabled" or readonly="readonly" (described here: http://w3schools.com/tags/tag_textarea.asp)If you then keep the textarea the same dimensions as the previous, it'll look exactly the same.

Notice how you have <!-- and --> surrounding all of your CSS style? Also notice that where your javascript starts (line 78), you have a <!--, and the ending --> shows up around line 101. You need to move that further down to right before the ending </script> tag.

Don't use <img> for background images, style the table cells.The HTML way: http://w3schools.com/tags/tryit.asp?filena..._cellbackgroundUsing CSS: http://w3schools.com/css/pr_background-image.asp

What exactly is the error that you get? It'd be nice if you could copy and paste the exact error message here. And the problematic code too.

No wonder!The reason for this is because the code destroys the array.When "foreach($_POST as $key => $val)" reads $_POST['list'], it sets $key as "list" and $val as the array. However, the next line changes $_POST['list'] to whatever the result you get when you stripslashes and strip_tags from an array. Either it forced it to a string or resulted in a FALSE. Be more careful about these things! >_<;

Can't be right, the source you included only has 75 lines. I'm assuming whitespace problems? Or did you leave out something. Which is line 80 for you?

Try to use some code to catch errors you might have.adapted from the php manual: <?phpif (is_writable($filename)) { if (!$handle = fopen($filename, 'w')){ echo "Cannot open: $filename"; exit; } if (fwrite($handle, $_POST["story"]) === FALSE) { echo "Cannot write to: $filename"; exit; } //SUCCESS fclose($handle);} else { echo "Not writable: $filename";}?><p> The story you wrote will look like this:</p></br><p>" <?php echo $_POST["story"]; ?> "</p></br><a href="readfile.php">Check to see if the file wrote properly</a>

If you need help from the others in the forum, please be sure to include a question.If you're looking for a general tutorial on php, go to: http://w3schools.com/php/default.aspIf you're looking for content management systems, why reinvent the wheel? Get a wiki or something: http://en.wikipedia.org/wiki/List_of_wiki_software

A few questions...Do people browse directly to that page? Or does it get included from another? Is $list used as a variable elsewhere? Does $_POST['list'] get affected by any other code? Is there javascript that might affect the content of the <form> after it reaches the browser?The thing is, I took a few bits of your code, added in some data to fake the mysql connection, and it works fine. You can test it out:http://www.freelancedreams.com/test/test.phpThe source is here:http://www.freelancedreams.com/test/test.txt

Wait, I don't understand... Did you just add this code recently? Because it doesn't quite match what you posted before. You don't need to do a count and split the variable list, because it SHOULD be passed as an Array. $list = $_POST['list']; $sub = $_POST['sub']; if($sub=="true") { if(isset($list)) { echo("<br />\n"); foreach($list as $delete) { //This should work??etc etc

To tell you the truth, I'm stumped too. I made a mockup of it and it seems to be working. Either see if the other forum members have any idea or I'll need more of the code to be of any help... >_<;

hrm... right BEFORE that "foreach($list as $delete)", add a line that reads: print_r ($list); and post what shows up there.

Cookies need to be set and handled in the HEADERS section of the html page. Simply said, this is an exchange between the client (the user's web browser) and the server (your server where the page is hosted) that happens before ANY of the HTML content is sent to the client.Meaning, if you already start sending content to the client (including <html>, <head>, and whitespace) then it's too late to set cookies. If you echo() anything, or close off php parsing and output HTML, then it's too late to set cookies.Here's an example. I just took the code that included setcookie() and moved it before the data. It saves the intended text as a variable $TEXT, which is output later in the page. // START OF FILE<?php$uname = $_POST['uname'];$pword = $_POST['pword'];if(isset($_COOKIE['user']) && $pword == "bobville"){ $TEXT = "You are already logging in.<br /><a href='index.php'>Return to the Main Page</a>";}else if($pword == "bobville" && !isset($_COOKIE['user'])){ setcookie("user", $uname, time()+360000);}else{ $TEXT = "Your password is incorrect, please try again.";}?><html><head>// YOUR HEADER INFO</head><body>// SOME HTML<div class='maintitle' align='center'> <div class='valign'>Logging In</div></div><br /><p id='update'><?php echo $TEXT;?></p>//THE REST OF YOUR STUFF

That method works because everytime the image is displayed, it shows up as having a different uri. Thus, when you load the page once, it might be pic1.gif?anything=42, and when you reload it'll be pic1.gif?anything=981. Because these uri are different, the browser caches them as different images, forcing a reload everytime (unless theres the odd chance that you get the same number again).

The problem is that you have to set cookies before you send ANY content to the client. Thus, all your setcookie() functions need to be at the front of your script.