Well at some point today, while thinking about nothing computer related, it came outa the blue how to make the way we handle strings in function calls even better. As well, seing it couldnt be further from Christmas, i figure its a good time for a presant ;)

So here it is. Download and check it out. Use them as much as you want, i dont care. Im using a standard as follows:

@invoke == string ready version of invoke
$invoke == inline string ready version of invoke

I also added support for \n for line returns. Should be quite usefull for most stuff you do. You can expect it to be integrated in the next ObjAsm32 version release as well (for method calls as well as normal API calls).

Comments welcome.
Enjoy!
:alright:
:NaN:
Posted on 2004-06-06 02:14:37 by NaN
Excellent work! It simplifies a lot all invoke sentences, saves typing and makes them more readable.
What else do we need?

I tested your macros in several programs and they worked without any problem.

Regards, :alright:

Biterider
Posted on 2004-06-06 13:38:16 by Biterider
Hi NaN,

If I use your macros like this

@invoke MessageBox, NULL, "@invoke Demo", "Pretty Cool", MB_OK
@invoke MessageBox, NULL, "@invoke Demo", "Pretty Cool", MB_OK

Would it duplicate "@invoke Demo" and "Pretty Cool" in data section? I know this is true for CTEXT("") macro but I was wondering if there is any way for macro to first check if there is the equal string already defined, and if so to use that instead of just defining duplicate.
Posted on 2004-06-06 19:21:57 by Mikky
No. They all fundementally work along the same line. In this case, you would have 4 entries (two per invoke) in the .const section. It dawned on me that most text used as API calls are unique. Text that get used over and over again typically are entered in structures, and the structures passed to API's (Like RegisterEx).

So i put the peices together to create these macros. I guess its best use would be for wsprintf. We all know what kinda pain it is working with this API ;)

Regards,
:NaN:
Posted on 2004-06-06 22:26:36 by NaN