Preventing PB_Event_FirstCustomValue Clashes Between Independent Libraries

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
Webarion
User
User
Posts: 39
Joined: Tue Sep 14, 2021 8:50 pm

Re: Preventing PB_Event_FirstCustomValue Clashes Between Independent Libraries

Post 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 :)
infratec
Always Here
Always Here
Posts: 7658
Joined: Sun Sep 07, 2008 12:45 pm
Location: Germany

Re: Preventing PB_Event_FirstCustomValue Clashes Between Independent Libraries

Post 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.
Webarion
User
User
Posts: 39
Joined: Tue Sep 14, 2021 8:50 pm

Re: Preventing PB_Event_FirstCustomValue Clashes Between Independent Libraries

Post 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.
Post Reply