Well, I’ve been getting back into EWL bit by bit lately. Sticking to smaller things like documentation fixes and bug fixes. This is good as it currently isn’t driving me up the wall and I can get my feet wet again.
We have been getting lots of great stuff from Peter lately. He re-did the Ewl_Grid to act more like the rest of EWL, to which we then gave him a whole bunch of suggestions on things that could be cleaned up or fixed. Hopefully he keeps it up as the work is greatly appreciated.
Other then that I’ve been doing some bug logging and some design work with Nathan. We’re currently working out how to best implement the drag and drop system in EWL. The current one has some limitations and some assumptions that aren’t valid and need to be worked out.
The main piece that we worked out last night is how to keep the DND events but not waste so much memory due to them. I want these to be seperate events in EWL but we also don’t want the four or five events adding space to each widget since their fairly specialized. (We briefly toyed with the idea of having one DND event that would tell you what type it of event it is.)
For the uninitated, the event callbacks are stored in an array of arrays in the widget structure for EWL. (There is a bit more magic then that but thats the basics). So, for each event in the system we add another entry to the array per widget. If you have a few thousand widgets this size can addup. (The structure is currently 8 bytes per entry, so having five extra entries for DND times 8 bytes per entry times a few thousand widgets adds up quickly.)
So, what’s the solution, well, it’s actually Nathans solution not mine but
here goes. When we create the array to hold the events we allocate it to
EWL_CALLBACK_MAX + 1 (so there is one extra field in there). Then, we have a
call to allocate a new event number in EWL. So, for DND position it could be
EWL_CALLBACK_MAX + 2, DND Status
EWL_CALLBACK_MAX + 3 and so on. Then,
whenever we get an event ID that is greater then
EWL_CALLBACK_MAX we stick
it into the array at
EWL_CALLBACK_MAX + 1, preferrably sorted by its event
ID to give fast lookup.
This way, we only store one extra entry per widget. This solution gives the ability to have as may different types of callbacks as we want in the system. The drawback being, if the list gets big it could be slower to find the events. (This is helped by the sorting and binary search of course).
You can comment on the current decussion happening at xcomputerman.com/bugs under the title EWL DND Improvements.