Two issues here.
1. Text->append(). I've done this. Pls see details below.
2. and we need another loop that's like a timeout loop but which can
manage malloc-ed memory for passing parameters in messages.
/*1. Text->append("string");
*/
How many times have you needed to append text to the end of a
Text_Display or a Text_Edit widget?
Almost always, right?
Well, both can be handled at once since Fl_Text_Editor inherits
Fl_Text_Display. On a 16 bit machine you'd need to do something else to
get to the end of the buffer, but this will handle a buffer up to 2 gigs
in size for a 32/64-bit machine and is a very simple, fairly easy to
understand implementation.
In Fl_Text_Display.H
* void insert(const char* text); // <-previous existing line in the file
void append(const char* text); // <-rs add
*
In Fl_Text_Display.cxx add this below Fl_Text_Display::insert(...) to
keep 'em sorta in order.
*/*
** Append "text" at the the end of the buffer and show the new position
*/
void Fl_Text_Display::append(const char* text)
{
insert_position(0x7FFFFFFF); // insert at end (32-bits max positive
integer)
insert(text); // insert
scroll(0x7FFFFFFF, 0); // scroll to end (32-bits max positive
integer)
}
*
/*2. msg_dispatch(Fl_Widget* receiver, uint msgID, uint nParams, ...);
*/
I'm not sure if that parameter list above is the right format for a
message dispatcher but the message dispatcher will need to copy the
parameters to new memory, mark it as not read, and send the message
(faked key presses, faked draw commands, movement, repositioning, etc.)
to the receiver (possibly looked up in a group so only the receiver
gets the message?) in a timeout loop a) to make sure it's asynchronous
and b) to assure that the event loop is running.
When the reciever returns, the memory (queued pointers may be marked as
reusable or freed on the spot. (Haven't thought about multi-thread
issues at all yet, but it must be thread-safe as well...)
This will hopefully GREATLY enhance our ability to do things like resize
and move sub-widgets to where they should appear and how they should act
in new composite classes.
-----------
BTW, my latest experiments with stay-on-top windows in KDE involve
grabbing a screen shot of the border before switching to override... ick.
But...
maybe.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
