https://vahidmy.blog.ir/post/679
Memory Templates Dialog ....
The Memory Templates are the ones you save in the ClipBoard, paste in your Source as Data, and execute with:
call 'USER32.DialogBoxIndirectParam', ...
They are more flexible than the ones saved directly by the Dialog Editor into Resources, and they do not have any of limitations that I have chosen to set, for simplicity, security and portability means.
If you wish to modify some behavior or some appearance of your Dialog, at run time, memory templates are a good choice. Just one example:
Depending on user action, you want to stand your dialog up screen or down screen. Maybe (I really do not know...), there is some api or some message you could send to your dialog to get what you mean. But, -if this *does* exist-, it will take you one hour, one day, one ... (!!!!) to find what, where, how in damned Win32.hlp. With such a template in memory:
[MyDialogTemplate: B$
D$ 090C400C2 0 ; style / extended style
U$ 03 ; control-number
MDTX: 0000 ; X pos
MDTY: 0000 ; Y pos
00DC 00C8 ; width hight
0 ; no menu
0 ; class 0 > default
'New Dialog' 0 ; title
08 'Helv' 0 ; Font'
...]
You can do:
move W$MDTY W$WishedPosition
... and it's done. (in this example, of course, DS_CENTER is off).
You can find such an example of modification in RosAsm Source at 'SetFindReplaceBox:' / 'SetSimpleSearchBox:' where the same Dialog data are used for both options with different sizes and Controls number.
You will notice that each control is a separate [data set]. This is because templates Controls must be dWords aligned: Don't remove the brackets. You can modify the data as you wish, like any other data set, but, of course with respect to according Win32 dialog data rules.
Your are responsible, too, for setting the names you wish for each template component. A Dialog Template, fresh out from ClipBoard, could look like this:
[Dialog: D$ 090C408C2 0 ; Style
U$ 03 0 0 0DC 0C8 ; Dim
0 ; Menu (not yet)
0 ; Class(not yet)
'Example Dialog' 0 ; Title
08 'Helv' 0] ; Font
[Control0: D$ 050040309 0 ; Style
U$ 02D 03C 064 018 ; Dim
07A ; ID
0FFFF 080 ; Class
'My Radio Button' 0 ; Title
0] ; No creation data
[Control1: D$ 050040001 0 ; Style
U$ 023 082 08D 018 ; Dim
07B ; ID
'msctls_trackbar32' 0 ; Class
'' 0 ; Title
0] ; No creation data
[Control2: D$ 050000000 0 ; Style
U$ 0A3 0B0 038 018 ; Dim
07C ; ID
0FFFF 080 ; Class
'OK' 0 ; Title
0] ; No creation data
Of course you might have to change the default namings for more meaningful ones, in order to avoid namings conflicts between several dialogs. Usually, having each control named by labels ('Control0:', ...) is of no use for you: It is just required by RosAsm syntax for data declarations.
You can edit all the records (and even add some entire controls 'by hand' if you want), and reload the dialog template in the editor... with respect to strict organization rules.
The routine for recovering the template from ClipBoard is not as flexible as you might wish >>> You must take care of the line organization (if, for example, one record is missing, the editor will abort; if you set ID record and Class record on the same line, if one record data is wrong, the editor will NOT correct the data, and results will be unpredictable, including a system hang inside USER32.DLL because of a zero division (I have seen this: The code of USER32 for Dialogs showing is not very secure -Your Dialog Data are supposed to be good-).
Before doing [Control][C] from your source, you have to carefully select your data from first '[' to last ']'.
One common error, when we add or delete by hand one control in a source template, is to forget adjustment of the n (Number of controls) record. This is the first member of 'Dialog Dim' line. If the number is wrong, the editor will correct it (Exception, it is set by the editor, anyway).
>>> U$ 03 0 0 0DC 0C8 ; Dim (n = 3, in upper example second line)
^^
As a general rule, you should avoid going back and forth between source template and dialog editor because it resets all your namings to default. I will make it more flexible and intelligent in the future. Often times, you just want to modify one or two value(s) inside Template. So, reload, modify, read the new data in the editor Edit Control, abort and write by hand the new value(s) inside your source Data. Simple and safe. If, after modifications of your data template, Win32 is unable to run your Dialog, do not hope that the Dialog Editor will be able to reload it... It is much more stupid than Win32 is.
For all common dialogs that do not need run time modifications, you should prefer the usual saving in Resources.
~~~~~~~