Page 2 of 2

Re: Preventing PB_Event_FirstCustomValue Clashes Between Independent Libraries

Posted: Fri Oct 10, 2025 6:20 pm
by Webarion
The issue with needing unique events is that it needs a unified approach. Because different hypothetical libraries assumed they were the only ones running they did not provide a way for other code to know what events were used. They could of provided a parameter to there own routines that designates a initial value for custom events and an additional way to know what events they reserved for their own use. In other words they need a cooperative and unified approach.
Your thoughts are exactly what I've been stating from the very beginning, and I've repeated them several times. It's possible we're talking about the same thing but using different words.

I agree that a unified approach is needed. The problem is that a library from an unknown author has no way to know which event numbers are already taken, because there is no single variable to track the next available number.

If we, as developers, all agreed by convention and documented that a global variable in the global scope (for example, EVENT_NEXT_CUSTOM_VALUE) should be used in our libraries as a marker for the next available event, that would be one thing. However, this rule would rely on every library developer adhering to it voluntarily, and there's no guarantee they would. Rules that aren't enforced at the compiler level are always broken. A gentleman's agreement relying on a shared variable implies responsibility from everyone towards everyone else. But how much responsibility do we truly have? Look at how many libraries have been abandoned and how many links are now broken. It's a good thing that at least someone is preserving this knowledge!

Therefore, I am absolutely convinced that a system for assigning unique numbers for custom events must be implemented at the compiler level, and not in any other way. Fred, these are thoughts for you, as the creator of the compiler :)

Re: Preventing PB_Event_FirstCustomValue Clashes Between Independent Libraries

Posted: Sat Oct 11, 2025 9:44 pm
by infratec
You can use #PB_Event_FirstCustomValue only once. That's clear.

But you can do something like that:

Code: Select all

; You can use this in each file:
CompilerIf Not Defined(CustomEvents, #PB_Enumeration)
  Enumeration CustomEvents #PB_Event_FirstCustomValue
  EndEnumeration
CompilerEndIf

; You can use the following enumerations in different files
Enumeration CustomEvents
  #Test1
  #Test2
EndEnumeration

Enumeration CustomEvents
  #Test3
  #Test4
EndEnumeration

Enumeration CustomEvents
  #Test5
  #Test6
EndEnumeration


Debug #Test1
Debug #Test6
All the 'libraries' needs to use CustomEvents Enumerations and it will work.

Re: Preventing PB_Event_FirstCustomValue Clashes Between Independent Libraries

Posted: Sat Oct 11, 2025 11:29 pm
by Webarion
infratec wrote: Sat Oct 11, 2025 9:44 pm You can use #PB_Event_FirstCustomValue only once. That's clear.

But you can do something like that:

Code: Select all

; You can use this in each file:
CompilerIf Not Defined(CustomEvents, #PB_Enumeration)
  Enumeration CustomEvents #PB_Event_FirstCustomValue
  EndEnumeration
CompilerEndIf

; You can use the following enumerations in different files
Enumeration CustomEvents
  #Test1
  #Test2
EndEnumeration

Enumeration CustomEvents
  #Test3
  #Test4
EndEnumeration

Enumeration CustomEvents
  #Test5
  #Test6
EndEnumeration


Debug #Test1
Debug #Test6
All the 'libraries' needs to use CustomEvents Enumerations and it will work.
At a minimum, this should be in the PostEvent documentation as the recommended way to obtain a unique event. But as before, there is no guarantee that everyone will do this.