Don't be. At the time I wrote that I thought I had fixed it, but turns out I actually only made it worse and start happening on my machine too lol

Now it's really fixed.

I hope.

EDIT:

And actually getting that message is something that will/should happen on more machines when using the current beta. For those who like to know the why of these things:

Opening and closing the door of a CD-ROM is an operation that can take a long time, speaking from a machine's perspective.

To prevent the API call that opens and closes the door from blocking the rest of the application until the operation completes (e.g.; you click the CD Control Icon and the dock freezes for a second or more), I use asynchronous I/O calls in a loop.

These calls are supposed to return a ERROR_IO_PENDING error while the operation is still underway (so that, in the mean time, I can keep the dock responsive to user input) and only return success when the operation actually completes.

Turns out the call was also returning ERROR_SUCCESS under certain circumstances instead of just ERROR_IO_PENDING. This caused two things: the routine to exit the loop prematurely, and for it to think there had been an error when opening and closing the door. This explains why you got that message, even though the operation itself was still underway and would eventually complete successfully.

Also, since the loop exited prematurely, many times this fooled the timing threshold used to recognize when the CD-ROM door was already closed. Result: an open CD-ROM's door would close and open again almost immediately. Not very useful.

It's an internal command (IC). So you right click the dock, select 'Insert New Dock Item-> Internal Command -> Disk -> CD Control'. This will add a shortcut to the CD Control IC on your dock.



Can you please post a screenshot here of the Item Properties dialog for this item?

I hope this is what you're asking for. BTW, if I click on anything in that dialog including the tabs, I get the same error message.

You erased out precisely what I needed to see lol

Since you're concerned about that, you can always send that image to the Winstep support address instead of posting it here.

Besides this, and if I understood correctly, the shortcut that gives you that error is in a *Folder* type tab of the Shelf (i.e.; a tab in the Shelf displaying the contents of a folder in your hard drive), not in the dock, right?

Hi Jorge, thanks for the instruction of how to get to the CD feature. Unfortunately, I also get the error message "Sorry, unable to eject media on drive D::". On top of that, it doesn't read my other DVD/CD drive. It's a USB external one. Of course, Windows reads it. BTW, if it reads more than one DVD/CD drive, does it display both without mouse-over?

As for the firewall shortcut issue, I sent it to the Desktop via Programs. Right-click> Send to> Desktop (create desktop shortcut).



It's under the Desktop tab in WorkShelf. It's not on the dock, but as I mentioned, I only placed it on the dock to see if it would work. I removed it afterwards. I only have things on my dock that I use the most with a few exceptions. I have Xtreme set to hide Desktop items at startup.

I'll send a new image right away of the Item Properties dialog to the Winstep support address.

Not sure I understand the question (I'm tired, sorry, haven't had time to sleep much these last few days).

This is how it works: if you have more than one CD-ROM drive, you have to add as many CD Control IC shortcuts to the dock as you have drives. Then you right click on each IC shortcut and select 'Dock Item Properties'. You will find that the 'Arguments' field in the dialog that pops up allows you to select which CD-ROM drive that particular shortcut applies to.

The drive letter will then be reflected in the icon itself.

Cool! It works! I placed one on my left dock and the other on the right.

Just in case you meant for the dialog to read 'Dock Item Properties', I thought I better let you know that the CD Control IC shortcut after right-click reads 'Dock Entry Properties' in case you want to change the terminology.

Again, not sure if some of the stuff was there before, but I'm like a kid in a candy store! I'm starting to notice things I didn't notice before. For example, one of the things I hadn't noticed before (or simply forgot) is instead of manually aligning the docks by eye, (I noticed they were off a bit while perusing the settings) I can easily align them by right-clicking on the Dock Control Icon> Dock Properties> Position tab.

I can also change the spacing and size of the icons on the dock under the Appearance tab, and a ton of other things! I haven't delved into the settings for these sort of things and some others for ages!

Almost forgot. Did you receive the image I sent to the Winstep Support address?

Now you don't even need to go through the right-click context menu to access the dock properties: just left click the dock control icon. There will be a short 600 ms pause (to make sure you are not double clicking the icon) and the Dock Properties dialog for that dock will open.



I did and I replied. I need one that does not have the path obscured, since it's the path that will tell me what I need to know.

Rats! I forgot that quick! Old habits die hard!

I just sent you the paths. I copied and pasted them instead. Don't know what happened. Never received a reply e-mail from you.

Windy. Man.

Look again at the paths for that shortcut. Both of them.

The 'Target' points to C:\Program Files (x86)\ which is where 32 bit applications reside. But then the 'Start In' path points to C:\Program Files\ (which is where 64 bit applications reside).

You can have one or the other, but not both without a catastrophic collision of the (incompatible) 32 and 64 bit worlds from the point of view of a 32 bit application such as WorkShelf/Nexus.

All I did was install the 64 bit version. I have no idea why it would have a path from 32 and 64 bits. I didn't pay attention to what the paths are since I assume I can't do anything about making it work within WorkShelf.

If it didn't work on the dock as well, then I would wonder if the path had something to do with it. But if it also didn't work when Xtreme is exited directly from my desktop, then I would definitely know something was wrong with the shortcut. I even tried putting it in My Documents and launching it from the Documents tab in WorkShelf but get the same error message.

I just tried something. I exited Xtreme then went directly to the folder and COPIED and PASTED (NOT Send to) the direct shortcut instead of the systray one to the desktop. I re-enabled Xtreme and tried WorkShelf again. I then got the following message. It does the same thing if I drag it to the dock from WorkShelf.



After all of this, I'm confused as to why the Send to desktop shortcuts (either the systray or the direct one) will work on the dock but not in WorkShelf. What is different between the dock and WorkShelf that allows one to work and not the other and is there a solution to make it work within WorkShelf too?

In WorkShelf, you are clicking a link to the actual physical shortcut file on a folder in your hard drive. When you drag that same shortcut to the dock, the dock first resolves the paths into something it can work with. Unlike the shortcut in the Shelf, those paths point directly to the application itself.

Look, it's simple to see the differences: right click the shortcut in the *dock* and select 'Dock Entry Properties'. Now compare the paths (the one that runs the application as well as the Start In path) to the paths that are in that shortcut you've sent me an image of.

See the difference?

New and final beta released!

Don't know if the new Beta release will have any effect on the shortcut issue, but I found a workaround/solution for the problem before I saw and installed the new Beta released today.

In all of the mucking around, somehow the Spider Solitaire shortcut started displaying the same error. I never touched it! It was working fine before I started trying to fix the firewall shortcut problem. It wasn't until after I fixed the firewall shortcut that I clicked on the Spider Solitaire shortcut to play and discovered the new problem.

I was able to make my firewall shortcut work by dragging it to the dock, deleted it from WorkShelf, and then dragged it back to WorkShelf and then deleted the one on the dock.

I tried it when I discovered the Spider Solitaire shortcut problem in WorkShelf but it didn't work. I followed the path in the Item Properties dialog and it pointed to something like "C:\Program Files(86)\Microsoft\ Games\SpiderSolitaire\SpiderSolitaire.exe" I checked, and there was only an empty Microsoft folder after "C:\Program Files(86). I could be off on the latter part of the path, but I definitely remember up to and including the \Games folder.

The reason I might be off is because after I went to that location and added folders that matched what it read in the path and followed the same process that I did for the firewall shortcut, it changed to "C:\Program Files\Microsoft Games\SpiderSolitaire\SpiderSolitaire.exe" and I didn't save the previous path because I had no idea that would happen. There is no icon/shortcut in the Microsoft\Games\Spider Solitaire folder I created in "C:\Program Files(86).

I'm not sure if this is a bug, but I still get the CD error message. I have two CD icons. One on the left side dock and one on the right.

However, it happens only when I click on the CD icons on the docks in short succession.

In other words, if I click on the icon and open it, then immediately close and reopen either drawer (for example even if I use the right dock icon to open and close the assigned drawer, and immediately click on the icon on the left dock to open the other drawer), the dock will hang, and any further clicks on the CD icon on either dock will show the error message.

Exiting and re-entering Xtreme clears the error message issue until that quick succession sequence is repeated.

Once cleared, (by exiting and re-entering Xtreme) I found through trial and error that if I wait about 5 seconds before reopening either drawer, the dock will not hang or display the error message.

This should be reproducible.