How to handle Windows equates across multiple classes and apps

questions
1

Theres got to be a better way to handle window equates across multiple classes and apps.

I’ve tried prefixing them in the past eg Prefix_WindowEquate Equate(001h), but this doesnt work across multiple classes, the compiler complains about the equates used in a class interfering with the equates in another class.

I’ve tried using omit wrapped around equates, but that then relies on the omit statement using the same name for those instances where the equates are the same but used in two or more different classes (or app files), so thats no good.

So is there a better way to stop the compiler from complaining about the equates when they are repeated verbatim across two or more classes?

Maybe there is a compiler switch or something that will ignore matching equates defined in separate classes?

I’ve tried
somename equate(001h),Private

but the compiler complains, so we have an elephant in the room when it comes to security and isolation, in that there is none.

TIA

2

I’ve just created an include file for equates that I use across a few classes. and include(),once in the inc file of each class. Works for me.

3

I’ll try that and see what happens.

Thanks.

4

If I want equates to be “local” to a class, then I give them a class based prefix. For example;
jf:CaseUpper, xf:CaseUpper and so on.

windows Equates, API functions and so on should always be unique-prefixed to avoid compiler warnings so as to create forward-compatibility with Clarion and other code.

5

I kind of expected the equates declared in a class to be only visible to a class. but then thinking about it, how could I call a class method from an app using one of its own equates as a parameter… :roll_eyes:

Because there are so many window equates, the number of compiler warnings is now causing the compiler to hang, and this is just for one class…

Thats why I wondered about if there was a compiler switch to switch off warnings about matching equates. Its a warning we dont need imo.

6

Equates declared in the CLW are limited in scope to the CLW.
Equates declared in the INC are in scope wherever the INC is included, and that’s typically (although not necessarily global.)

Of course wherever you INCLUDE it make sure you use the ,ONCE parameter. That’s important!

It’s a warning we definitely do need, because although you would think “an equate is an equate” it might not be declared to be the same thing in both places. All your own equates should be unique (typically by being prefixed.)

Cheers
Bruce

7

The warning is for the SAME LABEL.

The Equate(Value) could be DIFFERENT. The compiler does Not check the Value, nor warn about it.

Hence the need to be Warned as you may be passing the first declared Value that is wrong.

Using an INCLUDE file insures the value is the same everywhere.

If the equates are not needed outside the Class, then declare them inside the CLW and they will be Private. If I need Win API equates they are almost always in the CLW.

The compiler could probably be changed to compare values and not Warn. IMO that would just be encouraging and leaving SMELLY code. Because in the future if the Value needed to change, now you could have to fix many files or leave bugs.

8

I’ll try this as I’ve just started to write an app to manage the equates.

Does it cause problems though? The whole point of an equate is its a label for a value of sorts, so in your scenario, if the value needed to be changed for an api and they have the same label, then surely the other api’s that use the same label name need changing?

9

But in windows .h files they appear to be, so like I said to Carl, if the value has to change, then the name needs to change otherwise it will affect other api’s, because these equates are typically global in nature (unless added to the clw).

Looking at the SV equates, there are alot more defined in .inc files than .clw.

Anyway I’ll experiment with the equates in clw’s and see how that goes.

Edit.

Bruce, if its any consolation :wink:, because WinEvent does not support the up to date systray functionality, I’ve had to go through this learning curve to write my own systray class. :smiley: Currently 2403 lines of code in the class and the only other functionality I need to code into it is the Notification Area Flyouts. The rest of the functionality for a systray icon is now handled so it does everything required here:
Notification Area - Win32 apps | Microsoft Learn](Notification Area - Win32 apps | Microsoft Learn)

There are no restrictions or situations not handled and it works on XP upto Win11. :smiley:

It even handles the user status so no annoying popups in the middle of presentations.
Check User Status - Win32 apps | Microsoft Learn

And its all clarion source code with just 4 main methods to run the lot, once icons are loaded.

10

No idea if it even works or whether it would be helpful to you —
Check for SECTION in the docs. It is an optional parameter to INCLUDE.

11

I have seen the SECTION directive in the docs, it is used in some of the libsrc files, its an alternative to using OMIT or Compile, but there aint no easy way to do this, theres advantages and disadvantages what ever way is used.