However, there was one very big problem that I encountered early on – the “shellexecute” and “shell\verb\command” actions did not work very well when there were spaces in the path names.  Now, most of you would say, “well, did you quote the path names in double quotes?” – the answer is yes, I tried that.  In fact, I tried all sorts of things and found that the only way I could get it to work was by using double quotes and having to specify the drive letter.  That sucked – that meant that my portable USB key was no longer really portable, since if the drive letter wasn’t what was in my autorun.inf file, it wouldn’t run (or worse, run the wrong program).  So that solution wasn’t acceptable – I had to find a solution.

Well, after a bit of searching, I did come up with something… I decided to use the old MS-DOS 8.3 filenames to specify the path (the USB key was formatted with FAT32).  This worked for me and all was well – so long as the short filenames didn’t change, everything was fine.  However, I recently went out and got a new USB key (a nice super small one – pretty awesome) and noticed that Windows Vista supported a filesystem called exFAT, which is apparently the next filesystem after FAT32 and supposedly works quite well on portable devices (less overhead, less fragmentation, etc…).  So I formatted my new USB key using exFAT and copied all my data from my old USB key to the new one and figured it would just work as the old one did – wrong.

As it turns out, exFAT is actually pretty good… it even dropped the old short filename thing and now uses only long filenames.  Oh, yeah, damn… I was using short filenames in my autorun.inf.  Now I was really screwed – the one fix that I found worked for me was now out the door.  I need a new fix (I really wanted to try exFAT)!  So, I began searching again and to my disbelief, I finally found someone who had figured it out and posted about it (thankfully)!

The post I found was over at Wercshop, and the solution to the problem is to use two sets of double quotation marks.  I don’t really know why, and I really don’t know why this isn’t documented anywhere on MSDN that I could find – in fact, almost everyone seems to just ignore this issue (and one website said to rename your files and use underscores instead of spaces).

For those interested, here is the autorun.inf I use on my USB key:


[AutoRun]
UseAutoPlay=1
includeRuntimeComponents=True

action=”Load Start Menu”
label=”USB Portable Apps”

open=”Program Files\Start Menu\PStart.exe”
;icon=”Program Files\Start Menu\USB Stick.ico”

shellexecute=”"Program Files\Start Menu\PStart.exe”"

shell=load
shell\load=”Load Start Menu”
shell\load\command=”"Program Files\Start Menu\PStart.exe”"

[Content]
MusicFiles=0
VideoFiles=0
PictureFiles=0

I did notice a problem with RoboForm’s Firefox XPI toolbar plugin however, in that when you had a “minimalistic” window open (such as view source, or a JavaScript popup that had no toolbars specified), it would still attach the RoboForm toolbar to it at the bottom, usually hiding any horizontal scroll bar the window had. Now it’s not such a big deal to just click the little close box on the toolbar so I could use the scrollbar, but it is still very annoying since I tend to use the “view source” feature quite a bit. I also know that this is very much a bug in their program or adapter because I have other toolbars in Firefox which do not exhibit this same behaviour.

So I figured I’d be nice and bug-report the problem for them to ensure they were aware of it. I was somewhat surprised however with how their support staff (William, or so he decided to call himself since his Indian name is probably not “customer friendly” or something) has decided to handle it.

You wrote (2007/02/07 08:05 pm EST)
Hi,

With the RoboForm toolbar set to be attached at the top of my browser toolbars, whenever I “view source” in Firefox (and it creates a new minimalistic window), the RoboForm toolbar gets attached at the bottom of this new window, and seems to overlay the horizontal scrollbar (if present). I have also noticed the same behaviour when you get a popup window in Firefox.

I am running Windows XP SP2 with all the latest patches, under a normal user account with RoboForm2Go 6.8.4 running from a U3 usb key. My version of Firefox is “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1″.

I can send a screenshot if required – just let me know (I’m not sending one now in case that causes your systems any issues). I had checked your online FAQ but did not notice this issue mentioned anywhere so I am not sure if it’s known or not.

If there’s a fix (or if you’d like me to try a beta/patch), please let me know as I “view source” quite often and have to close the roboform toolbar all the time to use the scrollbar!

Thanks,

Eli.

John replied (2007/02/13 06:36 am EST)
This is already known bug. We are working on solution.

William replied (2007/02/18 02:06 pm EST)
Now we added option to RoboForm -> Options -> General: Attach to Firefox if Adapter is not installed.

Uncheck it and RoboForm will not attach to Firefox if its XPI is not installed.

You wrote (2007/03/26 06:45 pm EST)
Hi,

I am unfortunately still having problems with the RoboForm toolbar attaching itself to windows that it shouldn’t. I have upgraded to 6.9.1 (and also upgraded the FireFox adapter to 6.9.1) and I have unchecked the option to install the toolbar when the adapter is not present.

It seems to work sometimes that the toolbar isn’t displayed *if* my browser (Firefox) was already open before I launch RoboForm2Go. However, if I close my browser windows, then re-launch FireFox and “view source”, the toolbar is attached at the bottom overtop of the horizontal scrollbar.

Let me know if you require any additional information.

Eli.

William replied (2007/03/27 12:04 am EST)
you should uninstall XPI Adapter and never install it again.

only roboform can install adapter now — not you.

XPI Adapter from now on will only create problems.

You wrote (2007/03/27 02:56 am EST)
Hi William,

Ok, I have removed the Firefox XPI adapter now and it appears that the RoboForm toolbar is always attached at the bottom of my browser window, never at the top where the options are set to have it displayed. Viewing the page source also displays the toolbar.

I also enabled the checkbox for displaying the toolbar even if the XPI adapter was not installed (since I had to so the toolbar would display).

Eli.

William replied (2007/03/27 12:55 pm EST)
after you uninstall XPI adapter, you should reinstall RoboForm and check “Install Adapter” box in RF installer.

then it installs the new style Adapter that should do everything well.

you can also do it from RoboForm -> Options -> Adapter.
make sure you see only one new style (not XPI) adapter there.

You wrote (2007/03/27 04:52 pm EST)
Hi,

The RoboForm2Go installer does not have an “Install Adapter” checkbox, and the “Install Adapter” and “Uninstall All Adapters” buttons in RoboForm -> Options -> Adapter are both grayed out (under both Administrator and my normal user accounts) and I cannot click them (tried with Firefox open and also not open).

Eli.

William replied (2007/03/27 10:06 pm EST)
roboform2go can attach to Firefox only at the bottom.

upper toolbar is available only with RoboForm Fixed (installed on computer).

You wrote (2007/03/28 03:00 am EST)
Hi William,

Having RoboForm2Go only able to attach at the bottom of my browser window despite the options clearly stating it’s supposed to be attaching at the top would indicate a bug of some sort. Having to purchase/install the full version of RoboForm just so that I can have my RoboForm toolbar *not* attach on windows where the other XPI toolbars don’t attach is clearly not a fix I am willing to accept.

I would at this time like to request you escalate this ticket to your manager or to someone in the software development department of your company, as it is clear there is a bug (other Firefox XPI plugins do not have this problem, only RoboForm) in your product and I am attempting at helping you resolve this bug, however all your solutions provided to me at this time in trying to help me work around it have failed.

Eli.

William replied (2007/03/28 02:47 pm EST)
we removed this from Firefox page and it does not state this anywhere now.

now RF attaches at the top only if this is Fixed RoboForm.

RoboForm2Go attaches at the bottom for Firefox.

You wrote (2007/03/28 02:59 pm EST)
Hi William,

Please escalate this ticket to your manager. You do not seem to understand how to aid me in resolving this issue and I am starting to find your replies extremely unhelpful.

The option to attach at the top is right in the options for RoboForm2Go. I don’t care what your website says, it’s clearly stated and selectable as an option within the program.

It’s safe to say that at this point I’m extremely frustrated with trying to deal with William and his feeble attempt at grasping what the hell I’m trying to tell him. Hopefully I’m able to get the attention of someone a bit more in tune with customer support and actually get somewhere with this – like helping them fix the bug perhaps!