Memory dialogs revisited.

[hutch--]

I have always liked the technique but have not done much with it for some years. I did the original set of macros back in the Win88 days when it was genuine PHUN to debug, they are much easier to work with in development from Win2000 upwards. I am tempted to upgrade this set of techniques as it provides a fully self contained dialog capacity that does not use resource dialogs at all and has all the advantages of a scalable yet precision interface where you don't go blind and mad trying to line up controls in a dialog editor.

I have attached a test piece that takes ANSI strings. There are a number of ways of handling UNICODE strings, resource strings being the older technique but they can be stored as byte sequences and passed by address to UNICODE API functions for languages like Chinese and Japanese.

I think there is a viable method to do much the same with image data, store it as byte data, load it into a temporary file, read that file with LoadImage() then delete the file. The tests so far have been good and easily fast enough so if it looks like it viable, it would be easy enough to make a tool that loads the image file as DB data so the function can be called and return either a valid ICO or BMP handle from that data.

[donkey]

There is no need to create a temporary file with image data, you can convert an area of memory directly to a DIB. You simply have to create an empty DIB then use SetDIBits to read the transfer into the image. Much faster using the disk drive. If you have stored the full image the header can give you all the information you need to rebuild the DIB (color table etc...) even conversion to/from different palettes is fairly simple. Pretty sure I wrote a function to do it (in MASM it was that long ago) I'll have a peek at the old archives.

[hutch--]

Thanks Edgar, I would certainly be interested to see it. I wasted the time playing with CreateBitmapIndirect() but could not get it to work in a static control where the handle returned by CreateImage() works perfectly. If you create a temporary file using that flag the OS retains it in memory unless it is very large so the read back time with CreateImage is reasonably fast, the same technique can be used with an icon as well.

[donkey]

Hi Steve,

The archives are on DVDs and contain thousands of compressed projects/tools etc.. it will take a day or two. It should do icons as well, at any rate bitmap to icon conversion is pretty simple, I have many examples of how to do that.

[donkey]

I found one for icons held in data, its in GoAsm syntax though, translated on the fly (sorry about the square brackets I know you hate them  ) :

Code:

CreateIconFromData PROC pIconData:DWORD, iIcon:DWORD
LOCAL sz[2] :DWORD

/*
CreateIconFromData
Creates an icon from icon data stored in the DATA or CONST SECTION
(The icon data is an ICO file stored directly in the executable)

Parameters
pIconData = Pointer to the ico file data
iIcon = zero based index of the icon to load

If successful will return an icon handle, this handle must be freed
using DestroyIcon when it is no longer needed. The size of the icon
is returned in EDX, the high order word contains the width and the
low order word the height.

Returns 0 if there is an error.
If the index is greater than the number of icons in the file EDX will
be set to the number of icons available otherwise EDX is 0. To find
the number of available icons set the index to -1
*/

xor eax, eax
mov edx, [pIconData]
or edx, edx
jz ERRORCATCH

movzx eax, WORD PTR [edx+4]
cmp eax, [iIcon]
ja @F
ERRORCATCH:
push eax
invoke SetLastError, ERROR_RESOURCE_NAME_NOT_FOUND
pop edx
xor eax, eax
ret
@@:

mov eax, [iIcon]
shl eax, 4
add edx, eax
add edx, 6

movzx eax, BYTE PTR [edx]
mov [sz], eax
movzx eax, BYTE PTR [edx+1]
mov [sz+4], eax

mov eax, [edx+12]
add eax, [pIconData]
mov edx, [edx+8]

invoke CreateIconFromResourceEx, eax, edx, 1, 030000h, [sz], [sz+4], 0

mov edx,[sz]
shl edx,16
mov dx,[sz+4]

RET
CreateIconFromData endp

[Vortex]

Hi Hutch,

Here is a quick example to convert an image in memory to bitmap :

Code:

; On success, the function returns the handle to the bitmap otherwise it returns 0

.386
.model flat,stdcall
option casemap:none

include     \masm32\include\windows.inc
include     \masm32\include\user32.inc
include     \masm32\include\gdi32.inc

.code

CreateBmpFromMem PROC hWnd:DWORD,pBmp:DWORD

LOCAL hDC:DWORD
LOCAL hBmp:DWORD

    invoke  GetDC,hWnd
    test    eax,eax
    jz      @f
    mov     hDC,eax
    mov     edx,pBmp
    lea     ecx,[edx + SIZEOF BITMAPFILEHEADER]  ; start of the BITMAPINFOHEADER header
    mov     eax,BITMAPFILEHEADER.bfOffBits[edx]
    add     edx,eax
    invoke  CreateDIBitmap,hDC,ecx,CBM_INIT,edx,ecx,DIB_RGB_COLORS
    mov     hBmp,eax
    invoke  ReleaseDC,hWnd,hDC
    mov     eax,hBmp
@@:
    ret

CreateBmpFromMem ENDP

END

[hutch--]

Edgar, Erol,

Thank you both, its been years since I have done this stuff and i am a long way out of practice.

LATER : I have tested Erol's algo and it works fine, problem is it displays the alpha channel in an RGB/a bitmap as a black background. Rough guess here is that the later structure BITMAPV5HEADER appears to have the alpha channel data but I am just in the process of decyphering it. 

LATER AGAIN : That problem solved, must have a manifest file to get the alpha channel to be transparent.

[hutch--]

This is the working example of what I was after with both Erol's algo and the disk based on the uses LoadImage(). The direct memory load should be a lot faster but the LoadImage() version is a lot more flexible with scaling so I see a use for both.

The next trick I need is a similar algo to load an Icon from memory. LoadImage() does this fine but it may be a speed advantage i some contexts to have a direct memory load version.

[Vortex]

Hi Hutch,

With thanks to xandaz's code, I coded an application displaying an icon from memory :

Code:

    .IF uMsg==WM_INITDIALOG

        invoke  CreateBmpFromMem,hWnd,ADDR pIcon
        mov     hBitmap,eax

; Code portion from xandaz
                     
        mov     ii.fIcon,TRUE
        push    hBitmap
        pop     ii.hbmMask
        push    hBitmap
        pop     ii.hbmColor
        invoke  CreateIconIndirect,ADDR ii
        mov     hIcon,eax

[hutch--]

Gratsie,

I will digest this a bit later. I have added a couple of extra controls to play with, basically bitmap and icon versions that use the center image flag, just have to check that they behave in predictable ways. Getting both bitmaps and icons stored directly in code is very useful in that it allows complete object design for components that are fully self contained so they can just be linked and called without having to tweak the details for each use.

[hutch--]

Here is a test piece with 2 new macros to handle centered images. The original macros for both icons and bitmaps set the image location to the top left X Y corordinates. This extra pair allow a static control to be placed in an area of a dialog interface and will center any image loaded into them. They will also clip the image if its bigger than the control.

IMPORTANT : The attached ZIP file has the later version of DIALOGS.INC that has the extra two macros in it, replace the old one with this one, everything else is the same.

[dedndave]

works fine here, Hutch

XP MCE2005 SP2

[Vortex]

Hi Hutch,

I downloaded your example but it did not work on my XP Pro SP3. Could it be a manifest file issue?

[dedndave]

hiyas Erol
did you replace the dialogs.inc file ?
i used the one from the other thread (in the masm32 subforum)
perhaps they are different   

did it assemble properly ?

[Vortex]

Hi Dave,

I replaced the include file. No problem with building the project but running the executable does not display the GUI.