That's my thought too; I'm glad that you agree.

Alright, so next up is GUIFindThis. I'm a little confused on the output:
The way I read this is that bc holds the size of the element I looked for; de holds the byte right after the (in my case) GUIRLargeWin, and hl holds the lower byte of size of the first item popped onto the GUI Stack after the GUIRLargeWin. I'm not sure how that helps me, so I assume either I'm missing something, or have misinterpreted the output.

Part of that is your confusion, part of that is my copying the description of GUIFindThis from GUIFindFirst and not rephrasing. That should be:

hl = the first byte of the size of the specified element in the top group
de = the byte after the last byte of the top group.
bc = size of the current (specified) element

So then how does one get to the address of the specified element? And why does hl hold the size, and bc also holds the size?

So say you pushed four things onto the stack, a GUIRLargeWindow, then three other random things. If you use GUIFindThis to find element #0, it'll be the second thing you pushed (the one after the LargeWindow). Element #1 is the third thing. Element #2 is the fourth, and Element #3 doesn't exist. Each entry is structured as (low byte of size), (high byte of size), (type byte), contents. HL points to the low byte of the size; increment it three times to get to the first byte of the contents. BC obviously tells you the size of the element, instead of you having to calculate it via a _ldhlind call yourself. DE is more or less useless to you unless you plan to subsequently call GUIFindNext.

Ooooh, ok. That makes sense. So basically hl does point to the object. Works for me!

Next up, some just straight up ASM stuff. This seems like it should work to me:

Code:

Basically, I'm wanting (OutWindowE) += bc. So, I'm loading the value of (OutWindowE) into hl, adding bc to hl, and then storing hl back into (OutWindowE). Is that not doing what I'm thinking it does?

No, not at all. What you actually want to do is add OutWindowE,bc, not add (OutwindowE),bc. See the distinction? However, you can't change an address; that's already been assembled by Brass into an immutable number in your code, short of some SMC. I see what you're trying to do, though, and for this you'll have to use SMC. There's actually a routine in Document DE 7 that construction a MultiLine text input box in RAM to push to the stack, if that's what you need.

Nono, I don't want to change the address of OutWindowE. OutWindowE no longer does what it used to, it is now data.

Code:
And I want to increment that.

Ahhhh, my apologies for underestimating you. In that case, your code should do exactly what you said.

Hmm, ok. Turns out my issue is that bc is (I think) zero. This is after a GUIFindThis(1). What does it mean if bc is zero?

EDIT:
Some more testing shows that bc is, indeed, zero.

Generally that indicates a failure, so I suspect the macro. Aha!


Code:


Should be:


Code:
=

Ah, quite nice. I'm still not getting the excepted behavior, but I think that's something on my end. Three bytes after hl contains the contents, correct? Is that the contents of the whole thing, so the x and y coords etc? And does bc include those byte in its size?

And is there an easier way to increment hl a number of times rather than inc hl / ad nauseum? There apparently isn't a way to add a 16bit immediate to it.

I will add one of my ASM Woes since this is about those.... I can't figure this language out, anyone know a nice place with simple, detailed explanations?

This topic has some nice links in it. Hope that helps!

Thanks, I will bookmark it and look at those links when I get my brain running like normal again.

To be honest, I can't remember if bc includes the three prefix bytes, but I'm very much inclined to think that it does. And the whole contents will indeed begin at hl+3. To increment hl 5 or more times, it saves space to do ld de,number \ add hl,de. That's a 4-byte sequence, of course, and it trashed de, so be mindful of when it's actually the best choice.,

So next I need some GUI elements to pop up if a key is pressed during the mouse hook. This is what it looks like:

Code:
When I press Y=, my calc crashes. What am I missing?

Don't you need "ld hl,0" before calling the mouse? That's the only thing I saw

The GUIMouse(0) macro takes care of that.