I have many toolbar buttons that are mapped to the Windows shell.dll (C:\WINDOWS\system32\shell32.dll) to get access to the standard windows icons. Yet if I install DO on a different machine that has a C:\WINXP folder instead of C:\WINDOWS, how can I easily resolve this difference?
Weird, since XP should install to C:\Windows as well.
All the toolbars are XML files so you can open them in a text editor and do a search & replace to adjust the icon paths. Use an editor that lets you search & replace in multiple files at once to save time. (e.g. Textpad.)
You might be able to use %WINDIR% In place of the Windows path to make the toolbars work on both machines, although I'm not 100% sure this works for icon paths. Give it a try on one to see, if it's important that you can copy them back and forth.
If you 're-install' windows over an existing install without re-formatting, you could end up with a different install path (like C:\WINXP)...
I personally use: "%SystemRoot%\System32\shell32.dll"
In general, I believe the environmental variable %SystemRoot% is preferred over %WinDir% on NT-based Windows versions. But don't ask me why, because I have forgotten the logic behind this. I just remember when I had to script the installation of an application I supported at a very large corporation, the scripting lab had some very compelling evidence why %SystemRoot% was the better choice of the two variables. If you are on windows 95/98/Me--it's way past time to upgrade--use %WinDir%. I would suspect that Microsoft will phase %WinDir% out over time.
Along the same lines, if one wants a safer way to use icons or external application paths within Opus buttons, use paths like this:
Nero 6 Ultra - "%ProgramFiles%\ahead\Nero\nero.exe"
If one wants a safer way to use a subfolder of the current user's profile, use paths like this:
"%UserProfile%" = The profile folder of the current user.
If you are unsure about which drive letter is the system drive (which may not always be on the C: drive), use paths like this:
%SystemDrive% = the root of the hard drive partition Windows is installed on.
Here is a complete list of the Windows XP environmental variables from Microsoft and their purpose.
Thanks, that appears to work but I won't know for sure until I get back on my other laptop.
While changing the path in the "select icon" popup screen, is there anyway to delete the history of file locations that appear in the "select image from a file" field? My is quite full of inaccurate values and I can't seem to delete them. Is there a cache somewhere that can be deleted?
As you edit and create more custom buttons (and change their icons), the good and more recently used entries will "bubble up" to the top of the list and the bad ones will slide off the bottom, and eventually off the list entirely.
Here are some useful icons locations in Windows XP:[ul][li] Control Panel > System - %SystemRoot%\system32\sysdm.cpl[/li]
[li] Computer Management Console - %SystemRoot%\system32\mycomput.dll[/li]
[li] Downloaded Program Files - %SystemRoot%\System32\occache.dll[/li]
[li] Offline WebPages - %SystemRoot%\System32\webcheck.dll[/li]
[li] SystemInfo - %ProgramFiles%\Common Files\Microsoft Shared\MSInfo\msinfo32.exe[/li][/ul]NOTE: Both %SystemRoot% and %SystemRoot%\System32 are included in the Windows XP system path (%Path%). Opus will actually find any file in the system path, so if you just use "Shell32.dll" in the Select an image from file blank (without the full path), Opus will find it and you can select an icon.
While I would imagine NOT supported by GPsoft... check out:
HKEY_CURRENT_USER\Software\GPSoftware\Directory Opus\Paths\Recent\MRU\IconBrowse
Note:
The data in the (Default) string value are references to the 'other' string value names in this key which provide the path and filename to the icon file. If you decide to mess around with deleting any of the things in there to clean this up... I'd suggest that after deleting the ones you don't want that you make sure to rename whatever the remaining string values/icon file refs are so that they start at 00 and increment by one contiguously (00, 01, 02, etc), while then also making sure that the same number and names of these keys are reflected in the (Default) string value. So if you only end up with 4 icon files being referenced after deleting unwanted items, they should be named 00, 01, 02, and 03 - while (Default) value data would contain 00010203.
Skip all those and just add a junction: elsdoerfer.info/ntfslink/
?
I know you're a fan of junction points KC 
, but system environment variables will always work from system to system without first having to install and create the hard links you recommend.
[quote="steje"]?
I know you're a fan of junction points KC , but system environment variables will always work from system to system without first having to install and create the hard links you recommend.[/quote]
True but it is pretty easy.
-
Install NTFS link
-
Create empty folder called Windows.
-
Link empty folder to WINXP folder.
-
Done.
But like Steje says, it gives you no advantages over using env-vars.
It's an extra step while the env-vars for the Windows and System32 folders always exist on all machines.
It pollutes the filesystem with extra items which are duplicates of others, just for the purpose of something that's hidden from the user.
Plus there are issues with junctions confusing problems which don't understand them. (e.g. Change notifcation doesn't work in Opus when viewing a junction, at least in the current version. They confuse the used/free space counts in just about everything, too.)
Don't get me wrong; junctions certainly do have their uses (although I strongly discourage using them when you don't have to), but in this situation, what's wrong with using env-vars?
[quote="nudel"]But like Steje says, it gives you no advantages over using env-vars.
It's an extra step while the env-vars for the Windows and System32 folders always exist on all machines.
It pollutes the filesystem with extra items which are duplicates of others, just for the purpose of something that's hidden from the user.
Plus there are issues with junctions confusing problems which don't understand them. (e.g. Change notifcation doesn't work in Opus when viewing a junction, at least in the current version. They confuse the used/free space counts in just about everything, too.)
Don't get me wrong; junctions certainly do have their uses (although I strongly discourage using them when you don't have to), but in this situation, what's wrong with using env-vars?[/quote]
Nothing is wrong with env-vars, I use them. It just seemed that a junction could save a lot of work getting the icons to show up in the toolbar.
That's true I guess. Might be less effort, as a one-off, to create a junction instead of do a search & replace on the config XML files.
Anywho - didn't mean to sound too discouraging about the link proposal... I just figured a one-time effort in updating the toolbar DOP files would allow them to work on any system if he ever exported and imported over to another machine again like he's done already.
And yeah though - creating the links would be easy enough, but I was also thinking about the issues Opus has dealing with them. If theres ever a better way to manage junctions - I'd definitely use them. I like having all my working folders under 'My Documents' but don't have the disk space for everything on a single drive.