Åke has finished his Settings.xml Swedish translation. Thanks Ake!
settings swedish.xml
ViStart Dwwin Fix
Well it's summer time again. The UK is a disaster right now with the riots and all, too. Though I have no intention of staying in the UK for much longer.
Well for all you XP and Vista users, I thought I'd pump out another build of ViStart. I am aware of the winkey combo hook issue which plagues all ViStart users. Also Windows X has found a few minor bugs with DPI and ViStart's Orb. I will be looking to fix this soon too.
Changelog::
* Dwwin shutdown error possibly fixed
* Random parts of vistart showing at vistart launch
* Force menu close on each function/command
(Stable version updated on official site - http://lee-soft.com/vistart)
Well for all you XP and Vista users, I thought I'd pump out another build of ViStart. I am aware of the winkey combo hook issue which plagues all ViStart users. Also Windows X has found a few minor bugs with DPI and ViStart's Orb. I will be looking to fix this soon too.
Changelog::
* Dwwin shutdown error possibly fixed
* Random parts of vistart showing at vistart launch
* Force menu close on each function/command
(Stable version updated on official site - http://lee-soft.com/vistart)
Obtaining a handle to a 48 Icon is no longer a dream...
** Updated to include demonstration build at end of post
Obtaining a handle to a 48 Icon is no longer my dream... but I might as well take a trip around the world, its quicker and easier. It's been a while since I updated my dev blog, I will admit. We know ExtractIcon and any API that does the same function for all intensive purposes does not load "Very Large Icons / 48x48 Icons". I said I wouldn't give in and resort to bit block transferring of the icons, and I didn't. It's quite a long winded process.. not for the faint hearted.
The way to get a handle to the 48 icon of your choice is to use LoadLibraryEx passing it the file you want to get the 48x48 icon from as a data file (LOAD_LIBRARY_AS_DATAFILE) because we don't need to execute the code in there, we just want read access to the data. Remember icons come as groups in Win binaries, you want to isolate all the RT_GROUP_ICON resource types with their ID's. Assuming you don't know the resource ID for that group icon, you will probably know the group icon index though. In that case simply select the Nth group icon from the icon groups that you isolated. Where N is the desired group icon index. Then you have the resource ID for that group icon. I know.. by now you are thinking "Is it really worth this much effort" Well it would have been nice if Microsoft made an API that loaded 48x48 icons, I will go off on rant if I continue that train of thought so I will abort it. Hang in there mate!
So now we have the group icon resource ID, we have to find the specific individual Icon we desire.
So you then need to load the resource info (FindResourceByID followed by LoadResource) now that you have the resource loaded you will need to LockResource to get a pointer to that resource. Copy the resource binary data into a variabe, a byte array or string what ever using CopyMemory. We now have the resource binary data that contains our raw icon data as our variable in our exclusive memory space! celebrate. Sadly, we also have a bunch of other icons from the group. Select the icon that is the 48x48 icon using LookupIconIdFromDirectoryEx and passing 48x48 as the x,y desired parameters. Then repeat the above process to grab the binary data of the specific icon we want. Not far to go now!
Now its a case of creating an icon from the resource binary data, which can be done with CreateIconFromResourceEx. If you are still reading this, congratulations! you have a handle to your 48x48 icon. I will soon be posting a test build of ViSplore, thanks to this breakthrough..
I would like to say thanks to Google and about half a dozen people on forums that have had similar issues with icons in Windows. I didn't find these APIs by magic.
This build isn't a functional build as such, it's just meant to demonstrate the 2 components (ViFileView and ViTreeView) working in unison and show that 48 icons are obtainable from the module (Win\Sys32\Shell32.dll).
Obtaining a handle to a 48 Icon is no longer my dream... but I might as well take a trip around the world, its quicker and easier. It's been a while since I updated my dev blog, I will admit. We know ExtractIcon and any API that does the same function for all intensive purposes does not load "Very Large Icons / 48x48 Icons". I said I wouldn't give in and resort to bit block transferring of the icons, and I didn't. It's quite a long winded process.. not for the faint hearted.
- Load desired file into memory
- Pull out resource binary data for the icon
- Create an icon from such data, to give us a handle.
The way to get a handle to the 48 icon of your choice is to use LoadLibraryEx passing it the file you want to get the 48x48 icon from as a data file (LOAD_LIBRARY_AS_DATAFILE) because we don't need to execute the code in there, we just want read access to the data. Remember icons come as groups in Win binaries, you want to isolate all the RT_GROUP_ICON resource types with their ID's. Assuming you don't know the resource ID for that group icon, you will probably know the group icon index though. In that case simply select the Nth group icon from the icon groups that you isolated. Where N is the desired group icon index. Then you have the resource ID for that group icon. I know.. by now you are thinking "Is it really worth this much effort" Well it would have been nice if Microsoft made an API that loaded 48x48 icons, I will go off on rant if I continue that train of thought so I will abort it. Hang in there mate!
So now we have the group icon resource ID, we have to find the specific individual Icon we desire.
So you then need to load the resource info (FindResourceByID followed by LoadResource) now that you have the resource loaded you will need to LockResource to get a pointer to that resource. Copy the resource binary data into a variabe, a byte array or string what ever using CopyMemory. We now have the resource binary data that contains our raw icon data as our variable in our exclusive memory space! celebrate. Sadly, we also have a bunch of other icons from the group. Select the icon that is the 48x48 icon using LookupIconIdFromDirectoryEx and passing 48x48 as the x,y desired parameters. Then repeat the above process to grab the binary data of the specific icon we want. Not far to go now!
Now its a case of creating an icon from the resource binary data, which can be done with CreateIconFromResourceEx. If you are still reading this, congratulations! you have a handle to your 48x48 icon. I will soon be posting a test build of ViSplore, thanks to this breakthrough..
I would like to say thanks to Google and about half a dozen people on forums that have had similar issues with icons in Windows. I didn't find these APIs by magic.
This build isn't a functional build as such, it's just meant to demonstrate the 2 components (ViFileView and ViTreeView) working in unison and show that 48 icons are obtainable from the module (Win\Sys32\Shell32.dll).
 |
| ViSplore 48x + Component Test |
ViSplore Icon Blues
I am currently blitting a bitmap of a folder to the drawing context, which works fine except it doesn't support alpha transparency. Which presents a problem when applying a roll-over effect to a folder, I will of course require transparency. So I decided I would try to store folder icon externally as an icon file and use ExtractIconEx and DrawIconEx which supports Transparency. During the transition, A limitation was realized. The API mentioned above doesn't appear to support 48x48 (Vista Icons), the result is anything but pretty.
I will either go back to blitting but include 2 bitmaps (the rolled over effected bitmap and the standard folder). Though in this day and age, I don't see blitting as a viable option, when there's much more elegant solutions out there. Or I will find an alternative way of drawing the icons to the container's DC.
Lee
I will either go back to blitting but include 2 bitmaps (the rolled over effected bitmap and the standard folder). Though in this day and age, I don't see blitting as a viable option, when there's much more elegant solutions out there. Or I will find an alternative way of drawing the icons to the container's DC.
Lee
ViSplore (ViFileView) Update
A - 8:59 Ad - 12:59 Ado - 19:59 Adob - 24:59 Adobe - 30:59 Adobe - 32:59 Adobe D - 40:59 Adobe Dr - 44:59 Adobe Dre - 50:59 Adobe Drea - 56:59 Adobe Dream - 67:59 Dreamw - 36:59 Dreamwe - 42:59 Dreamwea - 48:59 Dreamweav - 54:59 Dreamweave - 60:59 er - 12:59 er - 15:59 er C - 24:59 er CS - 30:59 er CS5 - 36:59 |
|
After a few hours of tinkering I made a custom string formatter function that simulates the word break behaviour of Explorer (the implied behaviour of DT_WORDBREAK).
It works by using the DT_CALC_RECT flag in DrawText to calculate the size of a given string with other proposed drawing flags set. So "A" is 8px and "Ad" is 12px, etc. When the width is over a given threshold (59px in my example) then a break is inserted where the last separator existed on that line. That appears to be what DT_WORDBREAK did too, however, if there are no valid separators then the break is inserted where the width is over the threshold. Giving us the desired result (This is illustrated above)
the DT_WORDBREAK flag is a lie
Well, would you think that a flag named "DT_WORDBREAK" would actually break words? Well you would be wrong. In Windows Explorer the way folder text is rendered in such a way that when an item's name cant fit into the specified width it is dropped to a new line (breaking the word). I thought I could simulate the same behaviour with DT_WORDBREAK as the flag implies it would break words (Sadly not!). What's even more frustrating is that even the MSDN (Microsoft's official documentation of it's own API's) thought the same as I did. This isn't the first time that Windows API's has been misleading either - this is just one example. The documentation could at least state that it means it separates words where a separator is present (such as a space) - not BREAK them! Having worked with this convoluted mess for so many years I guess this is just a minor annoyance.
ViFileView for ViSplore
During the weekend I have been developing the new component (ViFileView) to be integrated into ViSplore. Now it is able to calculate the required number of rows and columns for any given number of items and work out the width between variable when given a minimum and maximum range. As illustrated above- It is also able to draw the default "medium" sized folder icon (Dynamic folder construction won't be available just yet).
Subscribe to:
Posts (Atom)
Posts
