TaskDialog

[zedd151]

How about not using __UNICODE__=1 and write the macro in the source?   

Code Select Expand

STRING MACRO data_label,quoted_text:VARARG ;; modifed from that in the masm32 SDK
    WSTR data_label,quoted_text,0
ENDM


How about simply using WSTR instead of calling one macro that will call it anyway?

Code Select Expand

    ; Unicode strings
   
    WSTR Sz_Radio1, "Lets do Item1", 0, 0
    WSTR Sz_Radio2, "Or maybe 2", 0, 0
    WSTR Sz_Radio3, "Super secret option", 0, 0
    WSTR Sz_MainInstruction, "You're about to do something stupid.", 0, 0
    WSTR Sz_Content, "Are you absolutely sure you want to continue with this really bad idea?", 0, 0
    WSTR Sz_WindowTitle, "cTaskDialog Project", 0

Works the same as the modified STRING macro had in the posted code, without having to put the modified STRING macro directly into the souce code. 

I didn't think of that before I posted the code above in #74.   

[NoCforMe]

So did anyone even try my homebrew version of this, beyond just getting it to assemble and link?

Regarding what sinsi posted below, I could add code to allow for a callback to the caller to process input and what not. Could replicate even more of the Task Dialog functionality.

Otherwise I guess I'll just take my toys and go home ...

[guga]

How about not using __UNICODE__=1 and write the macro in the source?   

Code Select Expand

STRING MACRO data_label,quoted_text:VARARG ;; modifed from that in the masm32 SDK
    WSTR data_label,quoted_text,0
ENDM


How about simply using WSTR instead of calling one macro that will call it anyway?

Code Select Expand

    ; Unicode strings
   
    WSTR Sz_Radio1, "Lets do Item1", 0, 0
    WSTR Sz_Radio2, "Or maybe 2", 0, 0
    WSTR Sz_Radio3, "Super secret option", 0, 0
    WSTR Sz_MainInstruction, "You're about to do something stupid.", 0, 0
    WSTR Sz_Content, "Are you absolutely sure you want to continue with this really bad idea?", 0, 0
    WSTR Sz_WindowTitle, "cTaskDialog Project", 0

Works the same as the modified STRING macro had in the posted code, without having to put the modified STRING macro directly into the souce code. 

I didn't think of that before I posted the code above in #74.   

A question about this macros.

WSTR Sz_Radio1, "Lets do Item1", 0, 0

Will it produce 2 zero null terminated string or 4 zero terminated string ?

Each ending 0 also counts as 2 characters on the unicode version or they are left over the macro and counts only 2 zeros anyway ?

[NoCforMe]

Code Select Expand

WSTR Sz_Radio1, "Lets do Item1", 0, 0
Will it produce 2 zero null terminated string or 4 zero terminated string ?

Each ending 0 also counts as 2 characters on the unicode version or they are left over the macro and counts only 2 zeros anyway ?

You'll end up with 2 too many zeros. Won't hurt anything but looks stupid.

[zedd151]

Just remove the extra zeros.
They are obviously leftovers from when I was playing around with the ugly Unicode strings either that or I simply pasted too many. 

Who cares what it looks like. The string itself is what matters, all characters are present.
I was quickly working to get the example posted, it worked fine so I posted it. It is only test code, not production code. Get a grip and pardon my errors. Jeezus!

At least I did not omit the terminating zeros. 
I was mainly testing my theory that no manifest was needed. I had proved that indeed it was not necessary, no matter who disagrees or what the MS docs might say.

Stop picking nits guys. In the end, an extra terminating zero or three will not crash the program after all.

[guga]

Just remove the extra zeros.
They are obviously leftovers from when I was playing around with the ugly Unicode strings either that or I simply pasted too many. 

Who cares what it looks like. The string itself is what matters, all characters are present.
I was quickly working to get the example posted, it worked fine so I posted it. It is only test code, not production code. Get a grip and pardon my errors. Jeezus!

At least I did not omit the terminating zeros. 
I was mainly testing my theory that no manifest was needed. I had proved that indeed it was not necessary, no matter who disagrees or what the MS docs might say.

Stop picking nits guys.

I wasn't complaining     . Just asked to understand how the macros behave in masm. I´m reading what you guys code (specially when they have default masm macros set), to make easier for me when i'll give a try on the translator.

[zedd151]

I wasn't complaining     . Just asked to understand how the macros behave in masm. I´m reading what you guys code (specially went they have default masm macros set), to make easier for me when i'll give a try on the translator.

It was just a mistake. No mystery. As I said a couple posts ago, I hardly ever have the need to use Unicode anything, at least not on purpose. So even using a Unicode producing macro is somewhat new to me, too. 

[TimoVJL]

That manifest thing is quite easy with ml64.exe, rc.exe and link.exe
https://masm32.com/board/index.php?msg=138123

Code Select Expand

ml64.exe -c TestTaskDialog2MS.asm
link.exe TestTaskDialog2MS.obj -subsystem:windows -manifest:embed


[guga]

That manifest thing is quite easy with ml64.exe, rc.exe and link.exe
https://masm32.com/board/index.php?msg=138123

Code Select Expand

ml64.exe -c TestTaskDialog2MS.asm
link.exe TestTaskDialog2MS.obj -subsystem:windows -manifest:embed


Hi Timo. It seems it is easy. There was no such thing when we started with RosAsm. When this thing showed up in (from windows XP as far i can remember), we didn´t payed too much attention on develop it further, and included something very very basics in RosAsm. Now, more then two decades later, i´ll need to update this thing.

[zedd151]

That manifest thing is quite easy with ml64.exe, rc.exe and link.exe
https://masm32.com/board/index.php?msg=138123

Code Select Expand

ml64.exe -c TestTaskDialog2MS.asm
link.exe TestTaskDialog2MS.obj -subsystem:windows -manifest:embed


So far a manifest is not yet needed as shown in my posted examples.  That being said, the TaskDialog test code so far is not implementing any callbacks. (The buttons aren't actually doing anything, etc.) it is simply displaying it.
I doubt that the callback code would need a manifest, but I cannot say for certain until an actual (working) TaskDialog is created, with all necessary callbacks being implemented.   

So guga, how is the next part of your TaskDialog coming along? (The callback procedures)
I'll be around if you need further assistance in making it masm compatible.

[guga]

That manifest thing is quite easy with ml64.exe, rc.exe and link.exe
https://masm32.com/board/index.php?msg=138123

Code Select Expand

ml64.exe -c TestTaskDialog2MS.asm
link.exe TestTaskDialog2MS.obj -subsystem:windows -manifest:embed


So far a manifest is not yet needed as shown in my posted examples.  That being said, the TaskDialog test code so far is not implementing any callbacks. (The buttons aren't actually doing anything, etc.) it is simply displaying it.
I doubt that the callback code would need a manifest, but I cannot say for certain until an actual (working) TaskDialog is created, with all necessary callbacks being implemented. 

So guga, how is the next part of your TaskDialog coming along? (The callback procedures)
I'll be around if you need further assistance in making it masm compatible.

The callbacks ? I didn´t implemented yet. I´ll give a try tomorrow after read the VB6 and russian forum. They have working examples.

But...most likely, as you said, the callbacks (actions) does not relies on a manifest file appended to it. I took a fast look on the disassembled code of this new comctl32, and despite the fact that it´s internal code is a mess, i didn´t found anything (yet) that suggests any relation between a manifest and the actions. This feature uses a lot of classes, btw, specially those from DirectUI, such as RegisterDUI70BehaviorFactory, and ActivateActCtx to handle the different used GUIDs. The others dlls it uses internally, seems to be the regular ones, such as EnableChildWindowDpiMessage, GetLastError etc.

[TimoVJL]

Application manifests

Application manifests are for OS loaders and are useful in many ways.
For example, COM user can use COM without registering COM component.

MS link.exe have supported manifest about 20 years.

EDIT: solution #5 use external manifest-file in development phase and add it to release exe with tool like in https://masm32.com/board/index.php?msg=138497 or create similar tool.

Understanding Manifest Generation for C/C++ Programs PDF