KevinM1

You won't need JavaScript if the rollovers are for hyperlinks only. For generic images that aren't links and other things, IE has had some issues getting :hover to work on anything other than anchors. I believe they only addressed that problem in IE7, so if you're not only using rollovers for links, and you do care about legacy browsers, then yeah, you'll need JS. Anyhoo, CSS rollovers are incredibly easy to create. The basic premise is to have both your 'on' and 'off' images in the same image file, either one on top of the other, or one next to the other. You set this image as the background of the element, positioning it so only the 'off' half is seen by default. During :hover, you then shift this background image so the 'on' part is visible. Some links: http://www.alistapart.com/articles/sprites http://www.oreillynet.com/pub/a/javascript/2001/03/23/rollovers.html http://www.elated.com/articles/css-rollover-buttons/

Why not use CSS rollovers instead?

It's not always possible to upgrade. Not every company wants to spend money every year to upgrade a system that is already working fine. And when they do upgrade a decade has past. Oh, I understand that. The best example I can think of is PHP 4 vs 5. It made sense that a lot of companies wouldn't switch originally. But now, with version 4 support gone, and PHP 6 inching closer to reality, it makes sense for them to at least switch to 5, which has been around for what, 5+ years now? I used to be like that, but found myself working more on the tools I needed rather than the projects themselves. I'm still generally weary of 3rd party code, but I have no problem using something like Code Igniter, Zend Framework, or jQuery. They're proven products that work and make my life more efficient. Given their popularity and seeming ubiquity, by the time I'd have to abandon them (or be abandoned by them) I'd probably have to migrate anyway.

I disagree. What if someone else wants to? Good point, although I don't see much reason to subclass here. If it was something more generalized, like, say, something more along the lines of PDO? Then sure. Have the constructor be a Factory Method that returns the correct underlying db object based on the structure of the DSN info, which then fleshes out the abstract public interface.

Unless you're Amish, you upgrade. Is there value in learning how things are done under the hood? Of course. That's why the guts of most building block data structures (lists, stacks, maps, queues, etc) are taught. It brings to light the pros and cons of using such structures, and builds a sort of intimacy with them so you know when and how to use them properly. This is what the OP is doing, and more power to them. But in the real world, unless you're the guy writing the library code, or a hardcore computer scientist, you're not going to need to roll your own. And if it's something that ships with the language? Unless it's absolute crap, why bother addressing it?

This link should send you on the right path: http://www.google.com/search?q=javascript+tooltip&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

A few things: 1. Your data members (a.k.a., your properties) should be private. Leaving them public jeopardizes encapsulation. Also, unless you're planning on creating subclasses, you shouldn't have them protected. 2. Outside of a learning exercise, I don't see what the point of this class is. PHP already comes with an OOP extension for its MySQL stuff (see: MySQLi), and a more generalized data access abstraction layer (see: PDO). 3. Returning a multidimensional array is a redundant extra step. MySQL results are already multidimensional arrays, and the client code will just have to iterate through it all line-by-line anyway in order to use it. 4. The idea behind your cleanSQL method is good, but it's better addressed at the db level. PHP scripts should never use db root access. Instead, they should use a specific user account that has the bare minimum level of rights as needed to function. Not trying to be the turd in the punchbowl here, but it looks like you're trying to reinvent the wheel. I think a better exercise would be to create some sort of user management system. It'd force you to consider how objects interact, which is the most important aspect of OOP. How would you manage users? What about user groups? Or user privileges? How would you store/retrieve that info from the db? What about registering new users? Or logging user activity? It's a problem with several potential solutions, each more rewarding and useful than bolting on a few methods to preexisting code, IMO. Just some food for thought.

Put curly braces (i.e. { }) around $_SESSION['loggedin'] on that line.

That's pretty much it. Private methods have their uses, typically as bookkeeping/initialization methods that shouldn't be used by the client system.

You don't need a loop if you only need one row.

You can't increment a value that doesn't exist. Your original $count didn't contain anything. The function count and your manually created variable $count are two different things.

I read in an article that a good way to do it is to set the base size in pixels, then everything else in ems. I haven't tried it myself yet, but it sounds intriguing. Link to article: http://net.tutsplus.com/tutorials/html-css-techniques/six-ways-to-improve-your-web-typography/

Eh, window.onload isn't that bad. Yes, if you're going to be using a lot of 3rd party code, then using a framework is the way to go (I'm also a jQuery man), but for small-medium projects that don't rely on outside resources, window.onload is fine. And, if written properly, it's not hard to port it to a more flexible, framework-supported version down the line anyway, as the structure would essentially be the same (replace window.onload with $(document).ready, all getElementByX functions with CSS selectors, etc).

Okay, I need to see more of your code, especially where/how you've written the function I showed you, and where/how $JobNo is being created.

Try: $html = "code"; include("html2.php"): $html .= "goes here";

Okay, good. And what doesn't work, specifically? Are the options not being created? Do they not have the correct values? EDIT: Try - window.opener.document.getElementById('ESP').options.add(newOption, null);

Yes, but I'd like to see what is actually in the source, sans PHP. I want to see if the JS is actually being written correctly by the PHP.

Can you post just the JavaScript that's in your source code?

Why don't people read the stickied threads? Ninja EDIT: http://www.phpfreaks.com/forums/index.php/topic,58799.0.html Which is clearly a stickied thread in this subforum.

What do you mean by 'index number'?

What does CPAUG20 supposed to reference?

String concatenation uses a '.' as its operator, like so: echo $myValue . " some text";

Well, first, DateLogged isn't a proper PHP variable. It's a string literal, which is why it's being echoed as-is. Also, it looks like you're confusing the capabilities/uses of PHP and JavaScript. What it looks like you're trying to do is pass an element's value in a query string. PHP cannot obtain this value (at least, not easily). It doesn't work like JavaScript where it automatically keeps a representation of the HTML document that you can directly reference. So, you'll need to use JavaScript in order to fill in the rest. I suggest creating an event handler for a button's onclick event. You can pass into it the $JobNo value, and obtain the DateLogged value all at the same time: function processClick(jobNo){ window.location = "CompleteProof.php?JobNumber=" + jobNo + "&ProofDate=" + document.getElementById('DateLogged').value; } ... <button type="button" onclick="processClick(<?php echo $JobNo; ?>)">[Complete Proof]</button> This should give you something to start with.

Google is your friend: http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla:en-US:official&hs=TUh&ei=LVOJSszdAZaBtwes7tjnDA&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=Dilleniaupc&spell=1&cts=1250513848282

I agree. Given how simple PHP is, compared to some other languages, it's the perfect language to get one's feet wet in the subject. No need to worry about pointers, heap memory, writing copy constructors....