I have not DLGITEMTEMPLATEEX in my doc, but i think i understand what the Help ID is for. Nevertheless, this does not answer to the question: "How does the user define the IDs of the Controls?... Must have...


Betov.

PS. What is the lower Windows version assuming DLGITEMTEMPLATEEX?
You have it under 95?

The DLGITEMTEMPLATEEX structure is not defined in any standard header file. The structure definition is provided here to explain the format of an extended template for a dialog box.

For each control in a dialog box, an extended dialog box template has a block of data that uses the DLGITEMTEMPLATEEX format to describe the control. For a description of the format of an extended dialog box template, see DLGTEMPLATEEX.

// typedef struct {
// DWORD helpID;
// DWORD exStyle;
// DWORD style;
// short x;
// short y;
// short cx;
// short cy;
// WORD id;
// sz_Or_Ord windowClass; // name or ordinal of a window class
// sz_Or_Ord title; // title string or ordinal of a resource
// WORD extraCount; // bytes of following creation data
// } DLGITEMTEMPLATEEX;


Members

helpID

Specifies the help context identifier for the control. When the system sends a WM_HELP message, it passes the helpID value in the dwContextId member of the HELPINFO structure.

dwExtendedStyle

Specifies extended styles for a window. This member is not used to create controls in dialog boxes, but applications that use dialog box templates can use it to create other types of windows.

style

Specifies the style of the control. This member can be a combination of window style values (such as WS_BORDER) and one or more of the control style values (such as BS_PUSHBUTTON and ES_LEFT).

x

Specifies the x-coordinate, in dialog box units, of the upper-left corner of the control. This coordinate is always relative to the upper-left corner of the dialog box's client area.

y

Specifies the y-coordinate, in dialog box units, of the upper-left corner of the control. This coordinate is always relative to the upper-left corner of the dialog box's client area.

cx

Specifies the width, in dialog box units, of the control.

cy

Specifies the height, in dialog box units, of the control.

id

Specifies the control identifier.

windowClass

Specifies a variable-length array of 16-bit elements that identifies the window class of the control. If the first element of this array is any value other than 0xFFFF, the system treats the array as a null-terminated Unicode string that specifies the name of a registered window class.
If the first element is 0xFFFF, the array has one additional element that specifies the ordinal value of a predefined system class. The ordinal can be one of the following atom values.

Value Meaning
0x0080 Button
0x0081 Edit
0x0082 Static
0x0083 List box
0x0084 Scroll bar
0x0085 Combo box


title

Specifies a variable-length array of 16-bit elements that contains the initial text or resource identifier of the control. If the first element of this array is 0xFFFF, the array has one additional element that specifies an ordinal value that identifies a resource, such as an icon, in an executable file. You can use a resource identifier for controls, such as static icon controls, that load and display an icon or other resource rather than text.

If the first element is any value other than 0xFFFF, the system treats the array as a null-terminated Unicode string that specifies the initial text.

extraCount

Specifies the number of bytes of creation data that follow this member. If this value is greater than zero, the creation data begins at the next DWORD boundary. This creation data can be of any size and format. The control's window procedure must be able to interpret the data. When the system creates the control, it passes a pointer to this data in the lParam parameter of the WM_CREATE message that it sends to the control.



Remarks

An extended template for a dialog box consists of a DLGTEMPLATEEX header followed by a DLGITEMTEMPLATEEX structure for each control in the dialog box.
Each DLGITEMTEMPLATEEX structure must be aligned on a DWORD boundary. The variable-length windowClass and title arrays must be aligned on WORD boundaries. The creation data array, if any, must be aligned on a DWORD boundary.
If you specify character strings in the windowClass and title arrays, you must use Unicode strings. To create code that works on both Windows NT and Windows 95, use the MultiByteToWideChar function to generate these Unicode strings.

The x, y, cx, and cy members specify values in dialog box units. You can convert these values to screen units (pixels) by using the MapDialogRect function.

See Also
CreateDialogIndirect, CreateDialogIndirectParam, CreateWindowEx, DialogBoxIndirect, DialogBoxIndirectParam, DLGITEMTEMPLATE, DLGTEMPLATE, DLGTEMPLATEEX, MapDialogRect, MultiByteToWideChar

And it's not necessarily a bug - sorry my bad english

Maybe this will attract some potential volunteers to help with the project. Because I really need help with this project, it's too big for one programmer.

projmanager.asm (line 109, after ProjManProc.showsizers):
.showsizers:
        invoke  ShowWindow, [esi+TBaseWin.SizerLU], ebx
        invoke  ShowWindow, [esi+TBaseWin.SizerL],  ebx
        invoke  ShowWindow, [esi+TBaseWin.SizerLD], ebx
        invoke  ShowWindow, [esi+TBaseWin.SizerU],  ebx
        invoke  ShowWindow, [esi+TBaseWin.SizerD],  ebx
        invoke  ShowWindow, [esi+TBaseWin.SizerRU], ebx
        invoke  ShowWindow, [esi+TBaseWin.SizerR],  ebx
        invoke  ShowWindow, [esi+TBaseWin.SizerRD], ebx

        invoke  SendMessage, [hProjTree], TVM_SELECTITEM, TVGN_CARET, [esi+TBaseWin.tvItem]

; Set selected item bold.
        mov     [.tvi.item.stateMask], TVIS_BOLD
        mov     [.tvi.item.mask], TVIF_STATE
        push    [esi+TBaseWin.tvItem]
        pop     [.tvi.item.hItem]
        lea     eax, [.tvi.item]
        invoke  SendMessage, [hProjTree], TVM_SETITEM, 0, eax  

;--- scientica:
        ;assuming titForm is the image number too...
        push    edi
        sub     esp, sizeof.TVITEM
        mov     edi, esp

        push    [esi+TBaseWin.tvItem]
        pop     [edi+TVITEM.hItem]
        mov     [edi+TVITEM.mask], TVIF_IMAGE or TVIF_PARAM
        lea     eax, [edi]
        invoke  SendMessage, [hProjTree], TVM_GETITEM, 0, eax
        ;test    eax, eax
        ;jz      .error         ; TODO: add error code


        mov     eax, [edi+TVITEM.iImage]
        cmp     eax, titForm+1
        jz      byte .not_titForm
;                invoke IsWindowVisible, [esi+TBaseWin.hwnd]    ; don't work for me :/

;                jnz    byte .Visible
                       invoke   ShowWindow,[esi+TBaseWin.hwnd],SW_RESTORE

      .Visible:
      .not_titForm:

      add       esp, sizeof.TVITEM
      pop       edi
;---
  jmp     .qfalse
    

formclass.asm (line 44, FormWindowProc):
      cmp     eax, WM_SETFONT
     je      .setfont

        cmp     eax, WM_CLOSE   ; scientica
        je      .dontclose      ; scientica

.default:
     invoke  DefWindowProc, [hwnd],[wmsg],[wparam],[lparam]
      jmp     .finish

;----- WM_CLOSE ------------------------------
; Hide window instead of closing it.
.dontclose:     ; scientica
       invoke   ShowWindow, [hwnd],SW_HIDE
       xor      eax,eax
       jmp      .finish

;----- WM_SETFONT ----------------------------

    

Why to play around "sub esp, sizeof.TVITEM " when you can use local variable.

I have a question about whole design of Fresh. Do you like current look. Because I think about making Fresh in one window. See the attachement. In the center will be source editor. What is better in your opininon.

Saving stack space, we don't live in a world of unlimited resources and by dynamically allocate the "locals" (what I'm doing is basically to create a local, but it's placed within the "procedure frame space"), and it's also a very quick way of keeping track of which locals are used and which are just dead code (left overs after some test, my older sources are rather full of them )
I use this technique a lot now days, it allows me to quickly allocte a small amount of memory with out needing to allocate a whole 4 kb page wiht some API, this method means, no API overhead.

proc MyProc, arg1, arg2, arg2

.local1   dd  ?    ; when you declare variables here, between "proc" and "enter" they becomes local (refered by [bp-??])
.local2   dd  ?    ; they are defined in the stack
        enter
;   ...     some code
        return
    

scientica wrote:

Saving stack space, we don't live in a world of unlimited resources and by dynamically allocate the "locals" (what I'm doing is basically to create a local, but it's placed within the "procedure frame space"), and it's also a very quick way of keeping track of which locals are used and which are just dead code (left overs after some test, my older sources are rather full of them )
I use this technique a lot now days, it allows me to quickly allocte a small amount of memory with out needing to allocate a whole 4 kb page wiht some API, this method means, no API overhead.

Some misunderstood maybe. I am not talking about API memory allocation. I am talking about the same stack frame, but using "local" definitions: ( see stdcall.inc for details ) The advantage is that you have label names and you still can use the stack.

Code:

proc MyProc, arg1, arg2, arg2

.local1   dd  ?    ; when you declare variables here, between "proc" and "enter" they becomes local (refered by [bp-??])
.local2   dd  ?    ; they are defined in the stack
        enter
;   ...     some code
        return
    

        sub     esp, sizeof.RECT
        mov     ebx, esp
        virtual at ebx
         .rect RECT
        end virtual 
...
        add     esp, sizeof.RECT    

you example would look like this after enter macro:

ESP+24  EBP+16  ; arg3
ESP+20  EBP+12  ; arg2
ESP+16  EBP+8   ; arg1
ESP+12  EBP+4       ; return address
ESP+8   EBP     ; saved ebp
ESP+4   EBP-4   ; local 0
ESP     EBP-8   ; local 1

what I'm doint is simply to add a local at the stack. Thus
if I "allocate" a dword like this:
  sub esp,4
  mov ebx, esp
the stack look like this:
ESP+28  EBP+16  ; arg3
ESP+24  EBP+12  ; arg2
ESP+20  EBP+8   ; arg1
ESP+16  EBP+4       ; return address
ESP+12  EBP     ; saved ebp
ESP+8   EBP-4   ; local 0
ESP+4   EBP-8   ; local 1
ESP     EBP-12  ; <--- my just "allocated" dword --->

add esp,4

the stack look like this after above:
ESP+24  EBP+16  ; arg3
ESP+20  EBP+12  ; arg2
ESP+16  EBP+8   ; arg1
ESP+12  EBP+4     ; return address
ESP+8   EBP     ; saved ebp
ESP+4   EBP-4   ; local 0
ESP     EBP-8   ; local 1
    

BTW, what you think about Drag&Dock behaviour. I hope you understand what I mean. This is when you can drag the window near the border of some other window (dock site) and draged window becomes child of the dock site window. Then you can drag the caption of the window and undock it as separate window. When the window is docked, you have visible splitters to resize it.

It sounds like the kind of stuff I'd put in version 2 or "Fresh XP" version, it sounds like too much cooding for the first version, but yeah, that would be usefull/cool, but as I said, too much coding for a first version. I think priority should be set on getting the app to to what it's supposed to do, the non-form.design-GUI stuff is a later head ace

Yea, (unfortunately) you are right. Sometimes I have a leaning to improve user interface more than it's necessary on the current stage. OK.

Scientica, do you want to take "styles editor". It's very important, but I can't make it just now. This is the window opened when button beside "Style" or "ExStyle" edit windows is pressed. The common idea is to use ListView with check boxes to edit window Styles/ExStyles.

[EDIT]Hmm, some comments look like greek (bulgarian?) to me (the font I use has mapped greek chars and some math "chars")
Could you please translate these lines:
\; Òîâà å íîìåð íà âèäà íà áóòîíà à íå å áèòîâà ìàñêà
\; Òîâà âå÷å å áèòîâà ìàñêà.
[/EDIT]

I've made some major (or minor, don't know what to calss it as) changes to the WinStyle struct/macro, the bindedMask is replaced with _dsc (description). I'm currently debugging the code (the last column doesn't work when I fixed so that the other two column display data, I'll post the file as soon as I've gotten teh alst column to display the data correctly, which is soon I hope

[offtopic]btw, I don't know if it's international, but when something look like jibberish (even though one know it has some real meaning), it said that it looks like greek, thus there was an attempt to be a little pun there. /me, no comedian so you don't have to laught [/offtopic]

proc EditStyle, style, flags, ...whatever you need...

return edited/not edited style - depending how the user exit the window.
    

3. offtopic: I was afraid for a moment that you may think bulgarians writes using all these horrible letters.

; I am talking about this part.
  invoke  lstrlen, esi
  mov     ebx, eax
  inc     ebx