jeffman

When I run that code with 2013.01.10 , it works as expected. When I run it with 2013-01-10 , it returns 2012-11-30, which you say is the value you have been getting also. In my first post I asked "Do you mean to explode that string with a dot delimiter and not a hyphen delimiter?" Clearly this has been your problem from the start. The delimiters don't match. What's happening is this: because explode cannot find a "." character, an array with one element is being created. 2013-01-10 does not match the interpreter's expectations of of an integer, so it is casting the value to 2013 by itself. The undefined "values" are being interpreted as 0. Since mktime interprets numbers the way humans do, the first month is 1 and the first day is 1. Numbers less than one go backwards. So the first 0 puts you backward into December of 2012. The second 0 takes you back one day to the last day of November, 30. You would get some hints about this if you turned on error reporting. This is what I see. Line 5 is the mktime line. Notice: Undefined offset: 1 on line 5Notice: Undefined offset: 2 on line 5Notice: A non well formed numeric value encountered on line 5 I hope some of that makes sense.

Did you at least try strtotime() ? It returns a different value than you've posted, and when I pass that value to date(), it outputs the correct date.

nm

I'm not 100% sure what you mean, but it sounds like a LOT of work.

Do you mean to explode that string with a dot delimiter and not a hyphen delimiter? Anyway-- 2013-01-10 (with hyphens, not dots) is already a validly formatted date string* to pass directly to strtotime. The result is a Unix timestamp. EG: echo strtotime('2013-01-10'); // 1357804800 * as long as that is year-month-day format

The || operator means "or." If the object on the left side of || has a value or evaluates to TRUE, then that object will be returned. Otherwise, the object on the right will be evaluated the same way. In this case, if the object has a type attribute, then the value of that attribute will be returned in lower case. If it doesn't, then the tagName will be returned in lower case. I think it's really testing whether controlName is a single element or a collection of elements, and I guess it's working with form inputs. If the object is just one input, it will have a type. If it's a collection, the test returns the tagName of the first element in the collection. So maybe controlName was constructed by getting the child elements of something like a form?

Except for the menu and the icons at the bottom, your new version is so different from the old that it would probably be easiest to start from scratch. You can probably copy and paste the menu HTML and the icons HTML from the old into the new.

We could save time if you explain exactly what you want to search for and how much information you already have about it's location. For example, I once helped someone who wanted to extract her game score from a 3rd-party source. She knew her username, the id of an ancestor div, and the fact that her score would be in a p element. With that information, it was very easy to find her score.

All your PHP script needs to do is echo data. Since you want to refresh only your game table, then the data that gets echoed should not be a complete HTML document. Echo exactly what you need and nothing more. Your javascript will receive that data in the function that you pass in the success parameter of $.ajax. A basic success function will look like this: function mySuccess (response, status, jqXHR) { alert (response);} Obviously, you'll want to do something more interesting with the response data, but before you script that, you should try something this basic as a test. Also, this example assumes you are echoing a plain string. jQuery also lets you receive data formatted as another data type.

Video and animation are not very impressive. The best work is done by specialists in those fields. Being able to add them to your page is as easy as adding an image. But good video or animation will draw attention away from what YOU can do, and bad video or animation will make you seem foolish. I suggest that you start with someone else's web page that you like. Not because it is complicated or has fancy tricks, but because it looks good and organizes the content well. Without looking at the HTML, try to copy it. Then change the images, and color and text, so it becomes YOUR page.

This might be what you want. I'm not sure

It's OK. Most of us learned by modifying other people's scripts, making mistakes, fixing them.

I don't know for sure about anyone else, but I never visit any forums. I just click the new content button. My bookmark to the site also goes to new content. So I see everything new. My guess is that most of the senior members do that also. If you don't get responses, it's because no one here has the expertise to answer. Server-side, we are mostly PHP developers.

FWIW, some characters have special purposes in the world of cookies and form-type data. The = character is a good illustration. It binds a name to a value. When it does that, it should not be encoded. Routines for extracting data look for the = and use it to parse the data. If the value of the data included an unencoded = character, those routines will attempt to parse a name-value pair that doesn't exist. So now your data is corrupted. That is why we encode the = character. There are similar explanations for other characters that get encoded.

Oh, yeah. You can save a script with a .cgi extension. No compiling.

I suggest looking at the CGI Perl Module here, where you will find all the documentation and a link to the source at the top. It simplifies a lot of tasks we used to code by hand, but I would not call it intuitive. There is a beginner's guide to using it here. You'll appreciate the very simple form example 2-3 screens down.

You forgot the file. GET should be used only to request data, not to upload data. Anyway, the technique would be the same. If you're discussing the server side, the examples are complicated because PERL is poorly suited to this stuff. It was not designed for it. It was designed for scripting tasks on a Unix workstation. It was the standard for server-side scripting in the early years because it worked and other, better scripting languages had not yet been developed. If you have a choice I'd recommend learning PHP instead. It was actually designed for server-side scripting, and it is widely used. So. Do you really want to ask about Perl? Can you ask a more specific question? If you're having troubles with the HTML form, that's a different set of questions.

Are you trying to put #main in the vertical center of the window?

Pre-loading the images is a good idea, yes.

That's a lot more modern, yeah. Good idea, too, putting your pic names in an array like that. My own preference would not be to create an image element using innerHTML. I would create an original image as your first HTML did, and then just change the src attribute in your loop function. I also recommend creating image objects as your first code did so that the images are preloaded.* You could simplify that with a for or while loop. * which should answer davej's question.

Is it possible that this has nothing to do with browsers, and a lot to do with different screen resolutions used on your two different monitors?

<img src="picture1.jpg" mame="slide" width"400" height"300"> Probably the spelling. BTW, this is really, really old code. It would be more conventional today to get a reference to your image with document.getElementById() and assigning an id attribute to your image. It is also no longer necessary to use eval() to assemble strings. I think that was obsolete literally before the turn of the century. The comment tags at the beginning and end of the script can also be removed.

switch is not a function. If this is your whole script, you have no functions of your own, so all your variables exist in the same scope. They should be accessible everywhere. Something else is wrong. The first debugging measure you should try is var_dump($_GET); See what's really in there before you make assumptions about it. Problems with your include statement are probably path related. You can always view source in your browser to see how the document actually got assembled. Included files show up just like copy and paste.

Totally. Build the regex right into that. Especially if you already have one that's working.

I would personally find a way to explode the file into an array of unique records. Walk through each element of the array. Check the date of each one. And so on.