Ok, this is so wierd I know it's something I'm doing wrong.

I can't browse for msc files using the Workshelf browser (properties|find item).

Nor can I browse for or use an msc file in any Workshelf or Nextstart item.

For example:
I can drag an msc file (in my case, I use devmgmt.msc as a shortcut to the Device Mangler) to a workshelf or NS menu item. (I can drag as a copy or as a shortcut, it makes no difference).

When I click on the icon created, Winstep says "no such file". When I open the properties dialog and choose "Find Item", it browses to the correct folder (C:\Windows\System32), but the msc files are not displayed!

I checked, and they are not hidden nor system files. They are browsable and executable with any other application - Directory Opus, explorer, etc - but for some reason, the Workshelf and Nextstart browsers just don't display them.

I have full admin priveleges.

I've also checked using a *.* filename in the browse filename box, and it correctly shows all the files in the directory - EXCEPT the msc files!

What am I doing wrong?

Are you using the Windows common control browsers or the NeXT-style browser?

Jorge, I'm using the common dialogs.

Here's a picture of what I see:



In the middle is the properties dialog for one of the shortcuts.
On the left is the display of files I see in the WS browser.
On the right is the same folder (in Opus), showing the msc file exists, and isn't just a figment of my (possibly overheated) imagination.

If you need any more info, I'm happy to provide!

Hmmm... Open an Explorer window, open the Tools menu, then Folder Options, then click on the View tab. Make sure the system is set to display system and hidden files.

Jorge, that's my standard operating practise anyway. I hate not seeing hidden or system files and worse, not being told what extension a file is (who the hell has a tiny enough mind that they can't handle a G-D file extension in a file display? People can remember that suburbs and postcodes need to be right to send mail, why can't they deal with a 3-letter file extension? Jeebers! )

But you jolted my memory, and in NS folder prefs, I hadn't enabled system or hidden files. But after enabling both these settings, and then restarting NS and WS, there was no apparent change.

Maybe this is another 64-bit problem? Maybe the file resources aren't being reported when NS/WS does a folder:show all or something like that?

This behaviour seems to be consistent with the 64-bit control panel problems, maybe there's a common library call that isn't working as expected on x64?

One of the biggest mistakes MS made, if you ask me, was to disable showing file extensions for known file types in Windows by default - this one dumb move is responsible for the vast majority of virus infections out there.



I don't know, I suppose it could be... However, the File Browser dialog you see on the screenshot you've sent me is actually NOT part of NextSTART or WorkShelf, it belongs to the shell itself. So, whatever the problem is, it is external to Winstep Xtreme.

What happens if you use Explorer to browse that folder instead of Opus? Are you able to see the files?

Jorge, do you mean the browser on the left (which I thought was the WS browser), or the one on the right?

If you mean the Opus browser, that's been disabled as part of my attempt to find what's causing the problem.

If I open a simple Explorer window, it does show all system and hidden files, incuding the msc files.

The Opus browser is a 64-bit extension, and to help troubleshoot this, I've removed it completely from the shell integration (windows shell, I mean!), and subsequently restarting NS/WS shows the same dialog with the same files not listed. :(

The files in question do definitely appear in any external browser I use. I opened a couple of Delphi apps I've built, and browsed to the same folder, and with the 'show hidden' commctrl options set, those dialogs showed the files (msc) just fine. But then, those dialogs have the Delphi object wrapper, which must do something to the dialog instance to get it to show "hidden and system" files, because it's just a single simple setting (that's all I can understand, simple settings ;))

So it seems to be related to the "WorkShelf Browser" dialog... I can't see any difference between the window handle used when this dialog is open, and a "normal" dialog I open using Delphi (or even Windows explorer, if I right-click on a windows link file and browse for the target), so you're definitely using the same control as what I'm seeing, but it's just not displaying those files...

Keep trying. I'm happy to try anything at this point to help out.

BTW - you took the words out of my mouth. Hidden file extension is the single biggest mistake MS ever made (I used to work in network security, so boy do I hate that one "default decision"). That's what happens when a company assumes their audience is a lowest-common-denominator and can't handle a little extra information. Grrr.

I've also found that if I create a shortcut (or menu item) in Nextstart or Workshelf for any msc snapin, the executable isn't found by NS/WS.

For example, if I create a shortcut with the following properties:

I can "execute" this from a DOS prompt, 4NT, TakeCommand, or Windows Powershell, or from a RocketDock item, but not from within NS or WS, no matter what type of shortcut/execution type I specify.

When I do try to execute it within NS/WS, I get the error:

Windows cannot find '"C:\WINDOWS\system32\mmc.exe" C:\WINDOWS\system32\devmgmt.msc' Make sure you typed the path correctly, etc, etc.

This is definitely a system error being triggered, but I can't duplicate this error using any of the other execution alternatives (DOS prompt, desktop shortcut, etc), using the same string (even pasting it into a prompt or an NS edit field).


I can run the internal command "System Properties", which takes me to the property page where I can then start Device Manager, but that's as close as I get.

I'll keep trying different things to see if I can't characterise what on the X64 system isn't working as expected.

I guess one question to ask (maybe it's stupid?) is - can anyone else with a 32-bit OS run the command string given above from within Nextstart or Workshelf?

I've just discovered (after the system rebuild), that most of the folders under %windir% aren't seen by any of the NW/WS dialogs.

I tried to find out why my shortcut to the system restore application (C:\WINDOWS\system32\Restore\rstrui.exe) didn't do anything except come up with the "not found" error.

I tried navigating to the folder using the WS browse dialog (change icon routine in the shortcut property menu), and I can get to system32, but the Restore folder isn't displayed no matter what I try.

I even reset the ACL and user permissions, and tried to run the shortcut as "administrator", and I got the same error.

This is getting a bit frustrating - I keep having to go back to the Windows task manager and start menu for all the standard windows tools I rely on for troubleshooting and configuring. It would be great if we could figure out what isn't set up right on this system...

Instead of running everything including the argument from the command line, how about right clicking on the NeXuS/WorkShelf/NextSTART item, selecting Properties from the context menu and placing

C:\WINDOWS\system32\mmc.exe

in the Filename section and

C:\WINDOWS\system32\devmgmt.msc

in the Arguments section?



Is there anything special in the file attributes of the Restore folder compared to the other folders WS/NS can in fact display?

Aha! That's it - manually specifying the app path and executable, and the parameter path and executable, works - WS even gets the icon right.
Thank you, thank you, thank you. I hate not seeing a simple alternative.

I'm sorry I didn't respond much sooner than now - I stopped getting notifications for this thread. I must have unchecked the 'notify me' option when I last posted.

I'll try a few other things as well and get back to you.

WRT the "invisible" folders and applications, I've been working with an MS guy to solve some really sh!tty problems with Windows Update and Genuine Validation issues that seem to be a big problem with XP x64. He asked me to reset some acls on some of the windows subfolders (restore was NOT one of them), and that seems to have "fixed" some problems with msc files.

If I'd seen your suggestion before today, I would have checked to see if the new OS install fixed the problem (i.e. it was a problem with corrupt acls or permissions in the previous OS), or if it was the ACL changes I applied yesterday (i.e. it's a problem with x64 in general).

Maybe tbeller could verify if the restore applet can be seen by NS/WS?

I still can't see the restore folder, and there are no "deny" acl entries for users in that folder, and I tried adding myself to "power users" as well (they have the same perms as admins on that folder) to see if that "fixed" the browse in WS, but it didn't. I might try restarting WinStep and see if I can run it as admin specifically (rather than just me, which is an admin user but not administrator, if you get me). This is the direction the MS support guy is heading, too.