from Win32 API helpfile:
Quote
int MessageBox(
HWND hWnd, // handle of owner window
LPCTSTR lpText, // address of text in message box
LPCTSTR lpCaption, // address of title of message box
UINT uType // style of message box
);
MessageBox accepts
one address for LPCTSTR lpText.
Does anyone know a trick to put
more than one string in the window that is created by this function?
I already consulted the tuts of Iczelion, but didn't found anything usefull.
Hi
Mean you this?
.data
szCaption db "Information",0
szText db "Masm32",13,10
db "------",13,10
db "Masm32 example",0
.code
invoke MessageBox,NULL,addr szText,addr szCaption,MB_OK
hi ragdog,
happy newyear.
No not quite.
More like this:
.data
szCaption db "Information",0
szText1 db "Masm32",0
szText2 db "------",0
szText3 db "Masm32 example",0
.code
invoke MessageBox,NULL,addr szText1+szText2+szText3,addr szCaption,MB_OK
I want to do a separate thing with szText2
Hi Rsir,
Obviously that is an unworkable solution since it is completely contrary to how data is passed to an API or even the fundamentals of how addresses work at any level, you will have to concatenate the strings then pass a single address to the function. Use lstrcat to combine the strings then pass the result...
buffer db 1024 DUP (?)
invoke lstrcpy, offset buffer, offset String1
invoke lstrcat, offset buffer, offset String2
invoke lstrcat, offset buffer, offset String3
invoke MessageBox,NULL,offset buffer,NULL,NULL
Although I am sure that there's a way to write a macro for this, most here know how I feel about macros ;)
Thank you donkey.
I think your solution will work.
I realize that my 'pseudocode' looks funny, but you got the message.
Have a drink, prosit!
Donkey,
Your code works fine.
To diminish the size of the exec the decl of the buffer can even be:
.data?
buffer db ?
.code
thanks,
Rsir
Quote from: Rsir on January 01, 2009, 04:45:57 PM
Donkey,
Your code works fine.
To diminish the size of the exec the decl of the buffer can even be:
.data?
buffer db ?
.code
thanks,
Rsir
Hi Rsir,
That's a recipe for disaster, setting the buffer length of a C string you will be building to a single byte guarantees a buffer over-run, perhaps in your tests you got lucky since Windows allocates space by pages and you didn't pass the page boundary however you can't guarantee that this will always be the case. Anyway, a 256 byte buffer of uninitialized data adds exactly the same amount of space to your executable as a 1 byte buffer or a 10 MB buffer, it's just an entry in a table and no physical space in the PE is allocated.
-------------------------------------
sorry, you're right.
I made this mistake earlier and it then took me days to find out.