Archive
20100914 MKE PHP Meetup Live blogging
6:20 Intro, and new people introducing themselves to the group.
6:27 Aaron talked about his car, and introduced Kevin Schroeder, Zend Technolgies tech evangelist.
6:30 Kevin tells us of his background (cool nerdy stuff)
A book he wrote
Kevin offered $100 off zendcon in our group, as well as a drawing for a free ticket (1,400 value).
Drawing for a free version of Zend studio at tonights meeting.
In my opinion live blogging is very distracting to me…
Kevin is going into the framework now and it will take about an hour. Im done bloggin for now…
Zend Studio is pretty cool. Especially code tracing.
7:20 break time.
Javascript: Focus() on a textbox
A dirty way to run js script inline and bring focus to an element:
<html>
<body>
<form method="post" action="index.php" id="myForm">
<p> Login: <input type="text" name="pwd" id="pwd" /> </p>
</form>
<script type="text/javascript">document.myForm.pwd.focus();</script>
</body>
</html>
Notice that both the form and form element have an ID
Return key doesn’t play nice in web form using Internet Explorer
I ran across an interesting situation where some users of mine were complaining that a form I created “didn’t work”. Kind of strange to get this complaint after almost a full year of operation. I remember testing the xhtml and css design in both firefox and IE browsers and it all checked out. What I didn’t think of checking was the behavior of browsers when one presses the return key. With the help of Fiddler (thanks to Casey Williams for the Fiddler suggestion) this is what I discovered:
| IE | Firefox | |
|---|---|---|
| Submit Button Clicked | All inputs $_POSTed | All inputs $_POSTed |
| Return Key Pressed | All inputs $_POSTed except form buttons |
All inputs $_POSTed |
(For a larger, more detailed image click here)
As you can see, when my IE users were pressing the return key, the button itself was not being $_POSTed. So what right? Well what if you were checking if the submit button was pressed before doing any processing? Like so…
< ?php
if(isset($_POST['button_name'])){
// validate the user entries...
}
?>
This would fail if the user hit the return key in IE7. I haven’t tested earlier versions.
View the example. Test it in both browsers.
Right now the only thing that was suggested to me was to add a hidden field to mimic the submit button in your form like so:
<form ...>
<input type="hidden" name="button_name" value="whatever"... />
</form>
That works just fine.
From perusing irc and several forums, the only response as to WHY this happens are comments like “It’s IE, what do you expect?”. I’m already annoyed that IE doesn’t think it has to adapt to web standards, but this ont really caught me off guard.
I’m wondering if any readers might have some input on my inputs ;P
Talk like a pirate day 2008
Ahoy there!
Just a reminder that today is talk like a pirate day! Arggghhh!
All posts and comments for today will be translated in to pirate speak by using the nifty text plugin from Dougal Campbell. It looks like it hasn’t been updated in a while, but it still works. At least in version 2.1.3.
So what are you waiting for people!? Let’s have some fun in the comments!
Screen shots a snap with Vista snip tool
I was searching my Vista accessories for hyperteminal and stumbled upon a built in screen shot tool in Vista called Snipping Tool. I’m sure to most it’s nothing new, but coming late in the game leaves for more surprises!
You can find it in the start menu -> all programs -> accessories.
By default there is an outline around any window space that you choose to grab. This can be turned off by clearing the check box in the options ->“Show selection ink after snips are captured“.
You can take snips of menus and the like this:
- Open Snipping Tool
- Press Escape
- Navigate to the menu, or start menu area
- Press Ctrl + Print Screen (PC)
- Use the snip tool
Of course to take screen shots of the snipping tool, I needed to use the old stand by Screen Grab Pro. Otherwise it took a selection of the desktop behind the app.