#macro directive is only supported in the Red preprocessor, not in the Red/System preprocessor, both of which happens at compile time (but in the Red case, is also there in the interpreter for compatibility?)
event/picked is described in event! section. Though, in a User Manual, we should put all those information together for easier reading.
@dockimbel That still doesn't provide the necessary information where it's needed, in the ON-CHANGE actor. So either ON-CHANGE is worthless or it can only be used in specific circumstances, which the application author must be aware of.
If I were you, I'd get rid of the ON-CHANGE actor, because it doesn't easily describe what change has happened to the widget and who did it. Go with ON-SELECT which is specific enough, along with providing OLD-SELECTION and SELECTION words for the application author to work with.
The GUI needs to be luxurious about what it provides to application authors, because this is where the nitty gritty of debugging happens, and it might as well be provided and debugged by the GUI once, so each application author doesn't have to write and debug their own code for it.
@dockimbel the information is not exposed where it's needed, in ON-CHANGE. besides, it's not intuitive to expose such related information in such two different ways as FACE/SELECTION and EVENT/PICKED.
If I want to send that information to a function called in the actor, I have to provide more arguments, than just sending FACE.
@dockimbel Please have a more macroscopic view of it. It's not a matter of 1-2 lines of extra code for that one widget, but a program with maybe 500 widgets, which I work with on a daily basis. That leads to a substantial amount of extra code to debug, and it gets really tiresome, when you've done it 200 times.
It gets a lot worse, when your widget is more complex. What is the content in EVENT/PICKED for a multi-select table or a field or a drop-list? Does EVENT/PICKED even work in all those cases? Would it then not make sense to map it to something more meaningful in all cases, so the application author doesn't have to remember this?
This is why I say: Really accommodate the application author and provide all the necessaries in easy to remember facets. Having the same information in two places is less important than trying to be sparse, and I think this is a lesson that REBOL GUI systems haven't learned.
event/picked, nor why you have troubles with information provided by event values. Getting back to more objective points would be helpful, otherwise I don't see this discussion going anywhere.
@dockimbel Yes I have a very specific model in my head and it has developed over about 15 years of working with REBOL GUIs.
The model picked, requires the application author to have intimate knowledge of individual widgets to know how to use them, and this will get worse, the more widgets are written for the UI.
You need to consider scale. Large programs with many widgets. Writing many different throw-away programs. Reducing the need for debugging and the need to write support code to make the UI system work correctly.
This requires that widgets at least have a sensible set of facets that are straightforward and uniform to work with. What these facets are, is something you find out over time, as you write applications with the widgets. Common facets can be selection, old selection, highlighting, face state, preferably stored in an object inside the face.
Later on, build accessor functions for providing a uniform interface for obtaining a selection from tables, fields, etc. This is also useful for traversing forms of very different faces with very simple loops.
Sure, internally, use EVENT/PICKED as you like, but provide the nicely formatted information, so the application author isn't burdened with it.
