We can certainly discuss it.
Here's the background on function pointers in DBPro:
The very first plug-in written for function pointers (although never released) was by me - it provided a function that allowed you to get a pointer to the current function. It was after discussions in the DBPro forum on how it worked that empty wrote and released his version. We both got working versions at about the same time.
Pro's:
1. You always get the pointer you want.
Con's:
1. It was a pain to use. You call the function initially in a 'do not run' mode and the pointer would be recorded.
2. You have a function that has two responsibilities.
3. Crashes when you get the function pointer value wrong.
A few years later, along came Torrey with his scripting plug-in - he also wanted function pointers so that they could be called from his plug-in. He wasn't aware of the work already done so he came up with his own method - scan through the DBPro user code for function entry points and store them in an array, then access them using an index into the array.
Pro's:
1. No calling of the function just to set the function pointer.
2. No code in the function related to function pointers (1 function, 1 responsibility)
Con's:
1. Inserting a new function or removing an existing function in your code will break all of your indexes.
2. Difficult to get the right function - depends on the 'join' order of the code before it is presented to the compiler (was it Blue IDE that allowed you to control the include order?).
3. Difficult to debug - i.e. is function number 5 the one you meant to call?
(To be honest, these are all one and the same problem).
So that's where we were when I needed to revisit the problem. I wanted:
1. No calling of the function just to set the function pointer.
2. No code in the function related to function pointers (1 function, 1 responsibility)
3. No calling the wrong function because of code changes or include order.
3. No crashes for invalid pointers - provide a diagnostic instead.
Points 1, 2 & 3 were solved by using a function external to the function you want a pointer to - the idea was already there in the original code, it just needed to scan forward for GET PTR TO NEXT FUNCTION and scan back for GET PTR TO PREV FUNCTION. The GET PTR TO THIS FUNCTION function is still there to provide the original solution.
Point 4 was solved by simply holding the valid pointers internally and checking against that when a function pointer call is made. You can even check that each function pointer is valid before use too (FUNCTION PTR IS VALID).
Con's are that you need to do a little extra typing for each function.
Now you want me to implement Torrey's solution as well. Why?
Although it is clever, it's simply too error prone for general use IMO. I'm willing to discuss it though, but the picture needs to change drastically for me to go down this route too.
