Re: [Gnumed-devel] Re: commits

[Karsten Hilbert]

> In a previous posting, I explained that on testing the behaviour of the 
> wx system, I did not get the ghost edit textctrl with the Queue,
> but using parameterized wxCallAfter ,  the ghost edit control bug was 
> still reproducible. wxCallAfter will not fix this bug.
> 
> The problem is that wx system doesn't fire any end edit events if a 
> default node is created, or editing is canceled.
...
> I think it's not worth it wasting time re-exploring this problem, when 
> the fix is there.
We don't have "the" fix yet only "a" fix (which can be worth a
million, though). If editing tree labels involved locking and
gymnastics going beyond wxCallAfter (and even that I doubt) it
would be mentioned *somewhere* in the docs or on the web. This
simply cannot be the intended way to do that.

Of course, we need to ask ourselves whether wxTreeCtrl
provides amenities to INSERT new nodes at runtime at all ? It
seems the edit events are intended to be used for EDITING
existing labels.

Now, there's a "dynamic" tree somewhere in the examples that
inserts nodes as you go along (it's got to to with browsing
source/doc strings by introspection IIRC) so we might look
there for inspiration.

I simply refuse to believe that using Queue or even
wxCallAfter is The Solution. I'm stubborn, I know.

What really worries me, however, is your assertion that
wxWidgets does not fire an end edit event when editing is
cancelled. The semantics of that aren't immediately obvious to
me.

> This would imply that all new nodes have to be created as default
> health issue, and default episode nodes on the backend *before* the 
> start of editing,
Yes, this is a logical consequence if to be done that way.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346