First up, fantastic language. It is amazing how easy it is to learn and use. Only been using it a week, but it is awesome. I've used a lot of languages in my time, and it's a real credit to those who have contributed to fasm that I now rate it as one of my easier languages to learn.

I am using a listview, and want to get some of the even notifications. I've been programming at a higher level for a few years, so I know how to deal with the events. Right now I'm using this to get the code:



And it works perfectly well. So the good news is, there is not a problem. However, I imagine that given what I've seen of the language there is a way to do this better. I thought I'd struck gold when I found the 'label' instruction, and I was really hoping that this would work:



but alas it was not so. Instead I found that I had to use a size operator rather than NMHDR (none of which are 12 bytes either). So my question is simple. Can I make a label for a structure starting from an address? That way I would be doing 'mov eax,[nm.code]' which looks a lot prettier (and when you think that I then have to work with much bigger structures like NM_LISTVIEW to get more details I'm not sure I want to keep counting bytes).

Mat

Try one of these:





FASM also has some "assume" macro (it does more/less what you want), but I never used it.

Yours "label nm NMHDR at lparam" doesn't make much sense. "label" directive can only define label at specified address, nothing else (no structure, no members, etc.)

What you probably want to do would be something like:


But that would be a bad mistake! "lparam" is defined as "label lparam at ebp+XX" (where XX is some constant number), but the NMHDR structure is not located at "ebp+XX". It is located at address pointed by dword at ebp+XX - eg. indirection. "lparam" is only a pointer to structure, not instance of structure.

Becuase of that, you need to load address of NMHDR structure from "lparam" first ("mov eax, dword [lparam]"), and only then access memory at that address ("[eax + NMHDR.something]", "[eax + 4]", etc.). Both can't be done in single instruction.

This is the most important thing to understand. You are forced to use at least two instructions because x86 does not support double indirection.

Thats a great help, and makes it much easier. It's still not as easy as it possibly could be, but it's a good step forward. It solved the problem of having to count up the bytes when using the extended versions of the structure.

Revolution, are you implying that other architectures may support double indirection? I figured it was not possible to nest at all in asm (which is a bit of a pain when you only have so many gprs).

I'm not on my computer, so I'll have to run some tests when I get home. The main reason I want this is for using ptAction in NMITEMACTIVATE for NM_RCLICK, I want to use TrackPopupMenu with it (I tried it counting the bytes and ended up with the menu being in the bottom corner of the screen).

Thanks again,

Mat

Yes. Some of the old mainframe instruction sets used to have such an addressing mode. Although the ones I have personally dealt with did not support the constant offset part, just the double indirection (and even then only for loads and stores, not for arithmetic).

That's pretty interesting... Not that it's particularly relevant to me.