.for, .endfor MACROS

[qWord]

optimizing loops with blocking functions is like makeup for dogs 

[mywan]

i feel better, now

some of the guys in here can't read code unless it is surrounded by ".IF/.ENDIF"   :lol:
i hate that stuff, but i want to use it so that the newbies are accustomed to it

While trying to learn from reading source basic ".IF/.ENDIF" is not a problem. But when it has a lots of nested ".ELSE/.ELSEIF" I find myself messing with the white space to try and make sense of it. It seems a lot cleaner to me to see jnz. That tells me immediately where it is going and why without tracking back up through the page to see what other conditionals are contained in ".IF/.ELSEIF/.IF/.ELSEIF/.ENDIF/.ELSEIF/.ENDIF". No matter how many times I get it straight I still have to rework the logical blocks through my mind when I go back.

Edit: Somehow double quoted the same quote.

[dedndave]

mywan - my point, exactly   :t

qword - what blocking function ?

optimizing loops with blocking functions is like makeup for dogs

some dogs are just plain ugly - lol
you and Hutch can both write bloatware for MS
my approach has always been:
1) if speed matters, make it fast
2) if speed doesn't matter, make it small
in general, i try to develop habits that are aligned with that approach
so - even if it isn't critical, i am developing the habits that i aim for

Ryan -

I wish they would elaborate on what exactly would cause it to fail.

a sentiment that has been expressed by more than one other member   

as for the errors that MSDN says may be encountered
1) if it has an incorrect hWnd, it should never get into the queue - DOH !
2) invalid message pointer 
again - if there is an invalid pointer in a message parm, the message should return an error

at any rate, i have never seen this error occur
and - if it did, there may be better ways to handle it than exiting the program
for example - you could just pull the offending message out of the queue and move on
but - i haven't seen anyone's code do ths   :P
i figure exiting the program is safer than dispatching an erroneous message

[qWord]

qword - what blocking function ?

functions that get into a wait-state (GetMessage()).

IMO it is most important to make code readable and understandable. Optimize code is worthless, if no one understand it. Even, if you do not share the code with others, the question is if you will understand the code in some years. This "spaghetti"-style (no .if/.while,...) requires a lot more comments and I don't think these will increase the transparency in any case.
My strategy is:  if (Speed critically) then (optimize as much as possible) else (make code readable)

[jj2007]

It's not speed, of course - but saving 4 bytes is always nice ;)

the question is if you will understand the code in some years. This "spaghetti"-style (no .if/.while,...) requires a lot more comments

True. It doesn't matter when you have 20 lines of code, but for anything more complex the HLL constructs help a lot - there is a reason why GOTO was banned from modern languages.

I use both versions, actually, and I couldn't really explain why I sometimes prefer a jnz...
But I definitely need colour:
   push ebx
   push esi
   ... 20 lines of code
   pop esi
   ... 20 lines of code
   pop ebx

Dave, under which circumstances can you produce -1? My windows always exit with zero...

[mywan]

functions that get into a wait-state (GetMessage()).

IMO it is most important to make code readable and understandable. Optimize code is worthless, if no one understand it. Even, if you do not share the code with others, the question is if you will understand the code in some years. This "spaghetti"-style (no .if/.while,...) requires a lot more comments and I don't think these will increase the transparency in any case.
My strategy is:  if (Speed critically) then (optimize as much as possible) else (make code readable)

As someone just getting started with asm I'm finding the "no .if/.while,..." structures quicker to comprehend than with them, even after already figuring out the logical blocks of the ".IF/.THEN", and this is other peoples uncommented code.  Hence the notion that it will create issues for me to understand my own code after some years seems unlikely. Absolutely love the "invoke" for API calls though. I am absolute not against macros and higher level constructs, but the assumption that these constructs always make code more readable just doesn't compute in some minds.

Coming from a nooby position the most valuable _missing_ feature is context sensitive help files. When I can't remember which jump "jnz", etc., refers to my editor is perfectly capable of going directly to "\MASM32\HELP\help.chm::/jnz.htm" simply by hitting F1 with the cursor over "jnz". Neither are the help files searchable. This for me, in both cases, is a lot worse than any lack of comments. It is, imo, well worth creating a project just to remedy this.

[jj2007]

the most valuable _missing_ feature is context sensitive help files. When I can't remember which jump "jnz", etc., refers to my editor is perfectly capable of going directly to "\MASM32\HELP\help.chm::/jnz.htm" simply by hitting F1 with the cursor over "jnz".

Good idea, but Microsoft makes it very difficult. In my own editor, I have chained two help files, so that F1 on WinByTitle opens the MasmBasic help file, while F1 on SetForegroundWindow opens the page in Win32.hlp (because it can't find SetForegroundWindow in the MasmBasic help). The same with *.chm files is a lot more difficult. If the bloody chm does not contain an exact match SetForegroundWindow.htm, you just get a boring "page not found" - and most of the time it's not even searchable. Stupid, very stupid :(

[mywan]

I just created a thread asking about interest in a help file project like this. I have seen it done very effectively with some scripting languages. Initially it needs to be done as <keyword>.htm all in the same folder. From there it can easily be compiled into an effective integratable .chm file. Certain standards should be set on the structure of the .htm files.