Date Range: Last 7 days containing posts.
Perhaps the most unhelpful error message of all time: Parameter incorrect. That's the error message that only a handful of Dreamweaver users were experiencing when trying to install Cartweaver3PHP.mxp version 3.1.13 into Dreamweaver CS3 or Dreamweaver CS4. Originally, we were getting reports of this issue from Vista users. We thought for sure Vista was the culprit. Eventually someone reported having the install issue on Windows XP. Most people had no problems installing the extension on both Vista and XP, yet for a handful of users the install would only fail. Since it wasn't just Vista anymore we could conclude that it wasn't a simple Windows OS issue, so what was it?
As the sole extension developer for Cartweaver, it was my job to figure out why this was happening. I turned to Tom Muck, PHP developer for Cartweaver, for some advice since he happens to be a long-time Dreamweaver extension developer himself. Tom gave me a few ideas to look into and we both tried to help customers with the usual extension trouble-shooting methods. Unfortunately none of our suggestions worked for our customers.
Debugging this issue was difficult to say the least, particularly because none of the Cartweaver team could duplicate the problem. If you're a programmer, you know that it can seem nearly impossible to fix something if you can't make it happen yourself. Similar to how one might debug a website having an issue, we had to determine what the customers who were experiencing the problem had in common with each other. I also had to try and determine what they didn't have in common with the people who had no trouble installing the extension. Usually this sort of approach proves fruitful and the issue can be narrowed down to some difference between systems. In the case of extensions, it is often another installed extension that's causing the conflict. I carefully compared lists of installed extensions between users who had the issue and did not find any conflicts. I was stumped.
Lawrence (founder of Cartweaver & owner of Application Dynamics Inc.) put together an email list for people having the issue who were willing to volunteer to help figure this out. One volunteer noticed that the install process writes files to the TEMP directory, and he pointed out that he believed it stopped writing files at a specific file. Once I heard this, I thought there could be some meaning there but couldn't find anything wrong with the last file that got written, the file directly before it, or the one that should have been written next.
Lawrence and I talked about it some more and decided to just try and repackage the extension and see if that worked. I was afraid that if it did work, we'd never know why the issue happened and it might happen again in the future. A part of me hoped it worked so I could make customers happy, but part of me wanted to know the reason the MXP wouldn't install so that I could make sure it never happened again. I tried packaging it on several different systems with several different versions of the Extension Manager. It was always the same result; the extension worked for all of us at Cartweaver but our volunteers still couldn't install it.
I'd asked our volunteers to send me their TEMP files and I started taking a closer look at their files. I stared at the files in Beyond Compare for what felt like days. I could not find a problem anywhere. Why though, were both of their systems stopping at a specific file? There had to be something wrong.
I was staring at the files in Windows Explorer and noticed something odd. The file's Last Modified Date was listed as December 31, 1969! How strange. I checked the file on the Mac in Finder and it was December 31, 1903! As it turned out, the file was missing a Creation Date even though it had a Last Modified Date. As you may have guessed, that was the cause of the install issue all along.
One part of this issue remains a mystery to us still. Why in the world did only a few people have the problem and not everyone? My guess is AV software or security setting were somehow set to not allow files without a creation date to be written, but that's just a wild guess. If you know the answer, be sure and let us know as it'd be nice to know.
Thanks to all the Cartweaver 3 PHP customers who experienced the issue for being so patient as we worked to resolve the issue. Hopefully I'll never encounter anything this difficult to track down again!
My membership in the 2009 Adobe Community Experts program has been renewed. Dan's has too. (He's sure got a way with words; I'm so boring.)
I'm honored to be part of the program. Thanks Adobe!
Happy National Regex Day!
To celebrate I'd like to share some tips for working with Regular Expressions that have helped me over the years I've been using them. I've got 5 tips to share today (#1 is already in the post on Ben Nadel's blog that I linked to but thought it worthwhile to repeat here, sorry if it is a dupe for you...)
Tip #1, for Dreamweaver Users: If you're a Dreamweaver user and need to build a regular expression, start learning about the Server Behavior Builder. When you create a server behavior, Dreamweaver generates a regular expression to match the code block(s). If you're in a hurry (or especially if you're just learning regular expressions), the regexes Dreamweaver generates can be a good starting point. You'll find the regexes it generates are in your user's Configuration in .edml files (which are XML files).
Tip #2, for CFEclipse users (assuming this works in other flavors of Eclipse as well): When you use the Search dialog (ctrl+H on the Mac), there's the obvious Regular Expression checkbox. With your focus in the Containing Text field, press Ctrl+Space to get a handy regex cheat sheet.
Tip #4, Debugging Regular Expressions: You'll most likely find yourself debugging a regex at some point or another, and for me its usually because I missed a use case. (That's when its time to update the use case document.) Any time I've got a regex that isn't quite working right, I trim it back. In other words, I do the opposite of what I described in the first part of my workflow tip above. Stop trying to match what you really want to match in its entirety, take a bit away from the regex at a time until it starts matching your use case file. (If you didn't make a use case file, now is the time to do it!) Then build that regex back up again little by little until you have it matching everything you want.
Tip #5, Application Comments: In the case of using a regex in an application (versus in Find and Replace), always, always make a comment on what that regex means in plain English terms and why you need to use it in the first place. Sooner or later, someone will look at the regex and quite possibly have their eyes glaze over -- it could be you! So do yourself and others a favor and take a couple minutes to comment it. If you're extra geeky you'll have your comment refer to your use case file so they can actually see exactly what the heck that fancy string of characters is supposed to match.
I Googled. I googled some more. I found lots of blogs where people asked in the comments how to wrap text in a CFGRID tag, but either no answer was given or the format was Flash.
Well, for the sanity of those on the same mission I was on, I shall blog the solution that satisfied my quest. (It may or may not satisfy yours depending on what you're trying to achieve.)
A simple line of CSS did the trick in my use case:
UPDATE: To fix IE, add
display:block; to the rule above.
That's it, one line of CSS. Hope it helps!
For the last few weeks there's been a lot of buzz about IE8 and how Microsoft intended to make IE7 the default display as not to break existing websites. Recently Microsoft decided to go ahead and render IE8 as itself and many seem to be relieved. I am still skeptical...
I've been meaning to blog on this topic, but I honestly haven't had time to keep up with all the online chatter about it and hence was unsure I should bother. Perhaps what I have to say has been said before? Oh well, I'm going to say it anyway...
What I haven't yet seen talked about is the possibility that a dot release -- or even a full version -- of IE may be incompatible with a website, leaving the web developer wanting to 'skip' it somehow.
The proposed "version targeting" would allow someone to declare the site's compatibility with a specific version of IE so that it would render as that version, despite what the user had installed on their system. For example, the user has IE 15, but the web developer declared IE 7. The IE 15 user is stuck looking at an IE 7 site.
That seems to be the common example that raises all sorts of concerns about the web, user experience, standards and what have you. But what if...
What if IE 9 renders my site perfectly, but IE 9.1 doesn't. IE 9.2 is also perfect. Fixing IE 9.1 would take 40 hours of work and my client doesn't want to do it. Shouldn't I be able to skip IE 9.1 somehow?
Please don't try to tell me that sort of thing doesn't happen. It's happened to me with other software. (Safari being one and QuickTime being another.) So it is fair to say that Microsoft could release a version (be it major or minor) of IE that I don't want to support.
All users shouldn't be forced to the lowest browser supported by the site. In my mind, users should get the highest browser supported. That is, a browser experience that is equal to or the next lower supported version than what they have installed.
Let's pretend I have a list of versions I support on my website that looks like this:
Let's say the user has 9.1 installed. I don't support it, they should get the 9 experience.
How does version targeting propose to handle such a situation? Is it something anyone has even though about or discussed? I don't know, and if Google knows it hasn't pointed me there yet.
So therefore I blog, in hopes to spark some conversation be it in my blog's comments or on other blogs.
I have few other odd-ball ideas around this topic but I'll start with this one and see where it goes before revealing more of my wacky thoughts...
It's been roughly 3 months since my last blog. I was almost afraid I've forgotten how! (I forgot my username and password; it took three tries to get in.)
There's good reason to come out of my unintended hiding I've been living in the last few months... I was reading Eric's blog and came across a post he made that stirred up quite a fuss.
Really, I'm not that surprised at the reactions. Reading something that Eric writes (or that anyone writes for that matter) is far different than hearing it spoken. Some people are far to easily offended by words, especially when taken out of context...
People are far too busy to read carefully these days and are quick to take a blurb out of context and run with it. I'll resist the temptation to ramble on about this topic.
Bottom line is, if I were as good a writer, I probably would have written the same thing as Eric did on the topic of diversity in conference speakers. I really couldn't have said it better myself and I'm sure just saying this much is enough to make some people mad at me. Oh well, I can't please everyone and not everyone is out to please me either!
I've spoken at quite a few conferences and it bothers me to think that I may have been chosen because I'm a woman. I'd like to think I was chosen because I know the subject matter well and am recognized by my peers, but who knows!
At least I know that if I were to ever be asked to speak at AEA, it won't be because I'm a girl!