Version 3 December features an improved xHelp, now included in the MasmBasic package.Inter alia, xHelp has learned how to add F1 context-sensitive help to qEditor. After extraction of the package (the archive in post #1 of this thread) with "use folder names", launch \Masm32\InstallXhelp.exe. Afterwards, you can select some text, e.g. CreateWindowEx in qEditor, and press F1. Compliments to Hutch who made such a great plugin interface for the Masm32 editor

And apologies that I stole the idea to create a plugin interface for RichMasm, too - PM me for details ;-)

Changes in the update of 26.12.2012 (attached to first post, details in \Masm32\MasmBasic\MbGuide.rtf):

AddWin$AddWin$ hEdit=CrLf$+"[one line more]" ; append some text to an edit control; this line appends the current date and time to an edit control:AddWin$ hEdit=CrLf$+"["+Trim$(Launch$("cmd.exe /C date /T"))+", "+Trim$(Launch$("cmd.exe /C time /T"))+"]"

WritePipeLaunch "cmd.exe /C time", SW_RESTORE, cb:hEdit ; launch an app that requires console input; show its output in the edit controlWritePipe "20:40:50" ; set the time; you may add a 0 as second argument if you don't want a CrLf sequence to be appended:WritePipe esi, 0 ; write zero-delimited string in esi, do not append CrLfRem will show an error message if the pipe was closed for some reason

it seems you've done a great effort for the new update. Did you burn the midnight oil?

Yes I did, Gunther - but I just fixed a "midnight bug". Launch$() returns output from a console proggie, but it is not designed for proggies that expect input, and it choked badly when I tried. Version 2 Jan b behaves better, it just returns La$? to indicate an error.----Changes in the update of 2 Jan 2013 concern the handling of pipes in Launch (more in \masm32\MasmBasic\MbGuide.rtf): dec ready2load ; set the "we launched a process" flagLaunchesi, SW_MINIMIZE, cb:hOutput ; cb: = we want to see the output

YES, fat and ugly (but harmless). Will be fixed asap, thanks for the feedback

The reason is that "abcd" is an immediate for the macro engine, not a string. For example, you can write mov eax, "abcd" or mov al, "x". But the macro can check for the <"> and then decide to treat it as a string. The bug didn't show up until now because all my test examples had more then four chars - and then JWasm & Ml are clever enough to realise "no, can't fit into 32 bits, so it must be a string". Cute, ain't it?

Ah I see.Indeed it's not harmful, just a little annoying.I was confused for a while why my code wouldn't compile, until somehow I reverted back the input message, and finally the assembler accepted it.

jeivarmarr

I have this problem Then the result is compilation errorMasmBasic.inc (5871): error A2102: Symbol not defined: CP_UTF8MasmBasic.inc (6288): error A2102: Symbol not defined: OFN_ENABLESIZINGMasmBasic.inc (6289): error A2102: Symbol not defined: OFN_ENABLESIZING