Icon problems with FileContents nodes

[Vurbal]

As part of the project I mentioned on the Easy Screencast Recorder thread I'm attempting to create what I'm calling a System Bar for Windows. The basic idea is to reimagine the (IMO severely outdated) Start Menu and Control Panel. I'll be creating a separate thread to get general input on it but I've suddenly run into a strange issue creating menus from text files.

I should probably mention this is on Windows 7.

The menu items in FileContents nodes suddenly started showing me incorrect icons. Instead of the icon I specify (using the /icon argument) every menu item displays the file handler icon you would see in a file manager. Here's where it gets really strange though. It didn't start happening until after I set the file associations for various standard image formats to XnView. At first I suspected XnView was at fault but it turns out the same thing happens if I associate the file extensions with MS Paint or GIMP. OTOH if I set it back to the Windows default (Windows Photo Viewer) that fixes the problem.

Here's an example when Photo Viewer is set to default:



And here's what it looks like when I change it to XnView:



This doesn't affect any other type of node. In fact it doesn't even happen to the icon set for the node itself or icons automatically extracted from an executable in the text file - just icons set using the /icon argument. A (semi) educated guess would be that they are being processed in a file system context for some reason rather than actually being opened.

Here's the NirCmd menu with various programs set to default for opening ICO files:

  Photo Viewer (Windows default)


MS Paint


XnView


GIMP

[mouser]

set using the /icon argument.

i was just about to tell you that you were imagining some feature in LBC regarding this mystery /ICON switch.. but then it occurred to me to read the help file for my application and it turns out there is such a thing after all.

i will see if i can find the issue, it sounds like it should be pretty simple -- it sounds like it's using the file extension only to look up the icon.

[tomos]

i was just about to tell you that you were imagining some feature in LBC regarding this mystery /ICON switch.. but then it occurred to me to read the help file for my application and it turns out there is such a thing after all.

-mouser (August 16, 2013, 12:56 PM)

yaay for help files

[Vurbal]

set using the /icon argument.

i was just about to tell you that you were imagining some feature in LBC regarding this mystery /ICON switch.. but then it occurred to me to read the help file for my application and it turns out there is such a thing after all.

i will see if i can find the issue, it sounds like it should be pretty simple -- it sounds like it's using the file extension only to look up the icon.

-mouser (August 16, 2013, 12:56 PM)

Heh. That's the problem with being able to write code in your sleep. You might not remember it when you wake up. 

However as I said it works fine as long as I don't change the file association from the Windows default. I suspect you're using a Windows API function that relies on Photo Editor and just assumes nobody will change it. Nonsensical assumptions are the building blocks of Windows after all.

[mouser]

messaged you with test version.

[mouser]

Ok so i have a question -- if in the /ICON field you specify the path to an exe -- does it get the proper icon from the exe?

so its only doing this when you do /ICON and specify the path to a file that ends in .ICO extension?

[Vurbal]

It works properly using the /ico switch with EXE icons. That makes sense because it displays the icon correctly when I don't use the /icon switch at all and the EXE file being launched has its own embedded icon.

For ICO or PNG files I get the odd behavior when anything but Windows Photo Viewer is the default for that particular extension.

The switch doesn't appear to support DLL files - at least not using the filename;# references I copied from regular LBC nodes. Not a big deal since I don't use icons on most of my menu items anyway.

[mouser]

I may not be able to fix this -- for file contents nodes, LBC relies on the system behavior for showing files, via a function called SHGetFileInfo, and it seems your system (all systems?) are set up so that if you set a custom handler for .ICO files, the result is that all .ICO files show up in standard file managers/explorers as generic icons.

[Vurbal]

That's what I was saying before. I assumed it was a file system function and the behavior was out of your/my hands.

One thing I'm curious about, though. It doesn't affect image files selected for a regular node (like a command or menu for example). Does that use the same code or does that use something else that's not compatible with FileContents nodes for whatever reason?

[mouser]

It doesn't affect image files selected for a regular node (like a command or menu for example). Does that use the same code or does that use something else that's not compatible with FileContents nodes for whatever reason?

yeah, the normal button icons are actually extracted from files once at time of adding them, and then stored as data.  this has some real pros and cons, but it's not dependent on the file system icon rendering.  when showing the contents of directories, however, i use this other method that shares file explorer icons (FARR uses this too by the way) -- the benefit is that the OS does the heavy lifting of finding the icons, the downside is you are at the whim of the OS for some of these issues.

[Vurbal]

I guess I realized that from looking at the saved files. And yeah, being at the whim of Windows always means you'll run into one ridiculous assumption or another.

One of the biggest challenges I've been running into lately is things that work completely differently depending on the parent process. If it's launched from the Run command or command prompt (explorer or cmd) it does one thing but if you try to run the same thing from a program like LBC or NirCmd it does something else. Or in the case of symlinks to EXE files it works from the command line (or so I've read) but doesn't work from explorer.

It's my own fault for sticking with Windows.