Why and wmTaskData4 ?

[Tom Thumb]

Mike Westerfield's "Toolbox Programming in C" contains a routine:

void HandleControl (void)
{
if ((myEvent.wmTaskData4 & 0xFFFF8000) == 0)
switch (myEvent.wmTaskData4) {

...

I can find no explanation for doing this. I believe it's just testing if any of the bits 17 - 31 have been set to one?

I'd be grateful if someone would explain why this is being done. I imagine I've missed something there or the IIgs Reference Manuals.

[Tom Thumb]

Oh, it's checking if wmTaskData4 is 32768.

[Tom Thumb]

On Wednesday, May 31, 2023 at 3:17:30 PM UTC-4, Tom Thumb wrote:

Oh, it's checking to see if wmTaskData4 is less than 32768

[stephen...@gmail.com]

Yes, that's correct. In this case wmTaskData4 holds a control ID value, and all the control IDs that the code wants to check for are less than 32768. The "if" check is OK, but it's not really necessary, since the code could just check for the control IDs of interest via the "switch".

I suspect the "if" check is there because the code was originally written in Pascal for the Toolbox Programming in Pascal course and then later translated to C. The "case" statement in ORCA/Pascal can only handle values up to 32767, making a check like this necessary, but the "switch" statement in C does not have the same limitation.

--
Stephen Heumann

[Tom Thumb]

Ahh, thank you very much.

[Tom Thumb]

May I ask though; why go about it this way: if ((myEvent.wmTaskData4 & 0xFFFF8000) == 0) rather than: if(myEvent.wmTaskData4 <= 32767) ?

is there a reason? or just a choice?

[stephen...@gmail.com]

On Friday, June 2, 2023 at 12:16:00 PM UTC-5, Tom Thumb wrote:

> May I ask though; why go about it this way: if ((myEvent.wmTaskData4 & 0xFFFF8000) == 0) rather than: if(myEvent.wmTaskData4 <= 32767) ?
>
> is there a reason? or just a choice?

That is probably also because of the translation from Pascal. Pascal doesn't really have unsigned integer types, so a value with the high bit set would be treated as a negative number. The bit-masking check excludes such numbers.

--
Stephen Heumann

[Dirk Froehling]

Am 02.06.23 um 19:15 schrieb Tom Thumb:

It is easier to read. :)

No, really. 32767 is meaningless in that context. wmTaskData4 contains a
bunch of seperate settings coded as bits, not a single number.

0xFFFF8000 is 1111 1111 1111 1111 1000 0000 0000 0000 in binary form,
and by ANDing wmTaskData4 with this number, you say "I am only
interested in the upper 17 bits, ignore the lower bits."
The IF condition then means "If none of the settings in the upper 17
bits is set, do the following."

Dirk

[Tom Thumb]

I get the ANDing to test if bits are set and that's what I thought first too but as far as I've read the only thing wmTaskData4 ever contains is a zero or a control id; it, wmTaskData4, isn't flags bits. Only after playing ANDing that I stumbled upon 00000000000000001111111111111111, 0x7FFF, 32768 triggers that condition <shrug>

Was just wondering why.

[Tom Thumb]

He has a sense of humor. I think he was just messing with me.

[Jerry Penner]

Hmmm, I don't think he was messing with you. The hex-style is a fairly
typical way to handle stuff like this. It's common in microcontroller
code.


--
--
Jerry jerry+a2 at jpen.ca

[Dirk Froehling]

Am 09.06.23 um 03:02 schrieb Tom Thumb:

I have to admit that I didn't really check what kind of values
wmTaskData4 can contain. You and Stephen are correct, it should contain
the ID of a control in your dialog.

But maybe it contains other things in certain conditions. Otherwise that
check would not be needed (if you only have controls with small ID
numbers). If the event handling is done for a modeless dialog, for
example, it would be useful to ignore all unknown events.

I just tried to explain the hex form in the statement. You don't need to
play with values to find out the meaning if you write a constant that
way. It is like a mask for specific bits.

No, I don't have a sense of humor.

;)

Dirk

[Tom Thumb]

Re: sense of humor. I was referring to Mike Westerfield and I was just kidding.

I appreciate the comments and I understand using AND and OR to test/mask bits fairly well. I just didn't quite understand it's use pertaining to wmTaskData4 and thought I must have missed something in the reference manuals, all too likely, as to why/when any of those bits would be set.

if as Stephen suggested it's a Pascal case statement limit of 32767 for all I know that is the most efficient way to test for that. I'm sure Mike Westerfield had a reason for doing it that way other than to see if anyone would ask why.