Using DLGTEMPLATEEX structure

[zedd151]

;-)

Ha ha. How much code do your macros expand to? 

[zedd151]

Anyway what I have learned here, is that the DLGTEMPLATEEX structure is not a structure to be used per se, but only to be used as a guide when creating in memory dialogs. Meaning it is not an actual usable structure as-is.

Seems that 'in memory' dialog boxes are not the way to go, in some instances. Especially if numerous controls will be added to it.

I used to use a registered window for most of my projects (going back several years), but have been looking to use dialog boxes more often lately.

Seems that using a resource based dialog box might be the best option. If numerous controls are needed however, maybe a registered window is the best way to go. Especially true if many controls are needed, and the controls need to be perfectly byte (pixel) aligned.

 
I have scratched the idea of writing the three versions of a test program as mentioned above. I would rather concentrate on finishing the project already started. It is almost ready. And I am no longer considering using in memory dialog boxes at this point. And certainly not going to mess with DLGTEMPLATEEX any further.

[TimoVJL]

DLGTEMPLATE(EX) have been always a dynamic struct, just a hint, how Windows OS read it.
Many languages have their own way to use it.
Those who bother to read an old books for Windows programming knows that.

[jj2007]

How much code do your macros expand to?

It's a bit over 500 lines around DialogBoxIndirectParamW:

Creates a modal dialog box from a dialog box template in memory.

It was hard work, and it works fine, but I rarely use the dialogs. I prefer event-driven programming with "real" windows

[zedd151]

I prefer event-driven programming with "real" windows

I usually do use real windows too. But I have been working with dialog boxes recently, and am converting some old code, switching from using windows to dialog boxes, and eliminating butmaps. I wanted to eliminate the .rc file altogether, but in memory dialogs seem more trouble than they are worth. (without using macros to do it)

[zedd151]

Anyway here are two versions of 4x4, that I am currently working on.

They both use a resource dialog box in place of a 'real' window.
One uses bitmaps, the other no bitmaps. The bitmaps look like crap. Originally they were 32x32 and looked okay, but I had doubled their size to display larger. 

Changing from a window to dialog box only yielded a slight reduction in code size.
Removing the bitmaps was of course a much greater reduction in size.

I still have to clean up the code, use loops where possible to further reduce the code, other minor details, etc., and a couple of other changes still need to be made before I post the source code.
Once finished, I will post the source in the Game Development board.

[NoCforMe]

Any controls can then be added the usual way using CreateWindowEx (as if we were working with a 'window')

A dialog is a window.

But yeah, once you have a dialog you can add whatever you want to it using CreateWindowEx(). But if you know what controls you want to add at the get-go, probably easier to put them into the memory template and let the dialog manager populate the dialog. That way you need zero code to add them, just some data.

[zedd151]

A dialog is a window.

Of course.

I have decided not to use 'in memory' dialog boxes after all.
I opted for keeping the simple resource dialog box.    at least for now.

[Vortex]

Hello,

I propose a very pracical method to use binary resource templates : extract the binary data from compiled resource scripts ( .res files ) with a tool. Employing this technique, you don't even need to know about the layout of the structure DLGTEMPLATEEX.

I modified the resource script below to remove the line referring to the menu defined with MENU IDR_MENU

Code Select Expand

#include "\masm32\include\resource.h"
#define IDR_MENU 10000
#define IDM_ABOUT 10
#define IDM_MNMIZE 20
#define IDM_EXIT 30

MYDIALOG DIALOGEX DISCARDABLE 20, 10, 186, 100, 18481280
STYLE DS_3DLOOK|DS_CENTER|WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_VISIBLE
CAPTION "Dialog box"
FONT 12, "System", 700, 0, 1
{
  CONTROL "&About", 110, "Button", WS_TABSTOP, 116, 8, 50, 20, 0, 1234049503
  CONTROL "&Minimize",120, "Button", WS_TABSTOP, 116, 36, 50, 20, 0, 1234049503
  CONTROL "&Exit",130, "Button", WS_TABSTOP, 116, 64, 50, 20
  CONTROL "  Masm Dialog Box", 4000, "Edit", ES_AUTOHSCROLL|WS_BORDER|WS_TABSTOP, 16, 8, 72, 20
}

IDR_MENU MENU
{
  POPUP "&File"
  {
    MENUITEM "&About", IDM_ABOUT
    MENUITEM "&Minimize", IDM_MNMIZE
    MENUITEM "&Exit", IDM_EXIT
  }
}

Running Resource Hacker, load the .res file and save the two components ( the dialog box and the menu ) to .bin files. Convert the bin files to text files with Hutch's Bin2db tool.

You can obtain Resource Hacker from this address :

https://www.angusj.com/resourcehacker/

Here is how the code should look :

Code Select Expand

.data
include    Dialog.inc
include    Menu.inc

Code Select Expand

  invoke  GetModuleHandle,0
    xor    ecx,ecx
    invoke  DialogBoxIndirectParam,eax,ADDR Dialog,\
            ecx,ADDR DlgProc,ecx
           
    invoke  ExitProcess,eax

DlgProc PROC USES ebx hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

      .IF uMsg==WM_INITDIALOG

        invoke  LoadMenuIndirect,ADDR Menu
        invoke  SetMenu,hWnd,eax


[NoCforMe]

I wanted to eliminate the .rc file altogether, but in memory dialogs seem more trouble than they are worth. (without using macros to do it)

Thinking about this some more, you could create memory dialog templates without using macros, using a function or two.

I'm not suggesting this in my usual anti-macro mode: clearly this is a case where you either need to use a macro (or two), or else some code to construct the memory template. And I honestly don't know which one would be easier.

Actually, once you write either the macro or the template-constructing code, it'd probably be equally easy. (But I think the macro would be more complex to write. JJ's 500 lines sounds about right.)

Anyhow, a function would need to take all the info necessary to create the memory template and lay it out in memory. Rather than a function with a zillion parameters, probably best to put the info in a structure, then pass that structure to the function.

I could probably cobble something like this together, if there's any interest.