[PATCH] TEXTAREA controls submit their contents
This patch makes TEXTAREA controls submit their contents when their form is activated. Note that I reworked the handling of the embed and widget members of the form structure for TEXTAREA controls. This was because I was getting crashes and corruption when the form attempted to submit itself. I think the various coercions between (void *), (Widget *) and (Embed *) were going wrong. Changing things so that widget == embed is also more consistent with the way the other embedded form controls are handled. Regards, Jeremy Henty diff -pru -- dillo2-ref/src/html.cc dillo2-cur/src/html.cc --- dillo2-ref/src/html.cc 2007-12-16 22:40:25.000000000 +0000 +++ dillo2-cur/src/html.cc 2007-12-17 01:59:29.000000000 +0000 @@ -3792,6 +3792,11 @@ static void Html_submit_form2(DilloHtml entryres = (EntryResource*)((Embed*)input->widget)->getResource(); Html_append_input(DataStr, input->name, entryres->getText()); break; + case DILLO_HTML_INPUT_TEXTAREA: + MultiLineTextResource *textres; + textres = (MultiLineTextResource*)((Embed*)input->widget)->getResource(); + Html_append_input(DataStr, input->name, textres->getText()); + break; case DILLO_HTML_INPUT_CHECKBOX: case DILLO_HTML_INPUT_RADIO: ToggleButtonResource *cb_r; @@ -4240,7 +4245,7 @@ static void Html_tag_close_textarea(Dill form = html->forms->getRef (html->forms->size() - 1); form->inputs->get(form->inputs->size() - 1).init_str = str; widget = (Widget*)(form->inputs->get(form->inputs->size() - 1).widget); - ((MultiLineTextResource *)widget)->setText(str); + ((MultiLineTextResource *)((Embed *)widget)->getResource ())->setText(str); html->InFlags &= ~IN_TEXTAREA; } @@ -4292,12 +4297,10 @@ static void Html_tag_open_textarea(Dillo Widget *widget; Embed *embed; - widget = (Widget*)textres; - embed = new Embed(textres); - EntryResource *entryres = (EntryResource*)embed->getResource(); + widget = embed = new Embed(textres); /* Readonly or not? */ if (Html_get_attr(html, tag, tagsize, "readonly")) - entryres->setEditable(false); + textres->setEditable(false); Html_add_input(form, DILLO_HTML_INPUT_TEXTAREA, widget, embed, name, NULL, NULL, false);
On Mon, Dec 17, 2007 at 02:21:58AM +0000, Jeremy Henty wrote:
This patch makes TEXTAREA controls submit their contents when their form is activated. Note that I reworked the handling of the embed and widget members of the form structure for TEXTAREA controls. This was because I was getting crashes and corruption when the form attempted to submit itself. I think the various coercions between (void *), (Widget *) and (Embed *) were going wrong. Changing things so that widget == embed is also more consistent with the way the other embedded form controls are handled.
Here goes the attached page... -- Cheers Jorge.-
On Mon, Dec 17, 2007 at 02:21:58AM +0000, Jeremy Henty wrote:
This patch makes TEXTAREA controls submit their contents when their form is activated. Note that I reworked the handling of the embed and widget members of the form structure for TEXTAREA controls. This was because I was getting crashes and corruption when the form attempted to submit itself. I think the various coercions between (void *), (Widget *) and (Embed *) were going wrong. Changing things so that widget == embed is also more consistent with the way the other embedded form controls are handled.
Yes, it looks much better. Committed. Please note that the enter key is selecting text instead of adding a new line... -- Cheers Jorge.-
On Mon, Dec 17, 2007 at 10:07:09AM -0300, Jorge Arellano Cid wrote:
Please note that the enter key is selecting text instead of adding a new line...
It's in the TO DO, along with the need for a scroller (and thanks for the example page, BTW). I have some tweaks and cleanups to submit first. Regards, Jeremy Henty
On Mon, Dec 17, 2007 at 03:19:13PM +0000, Jeremy Henty wrote:
On Mon, Dec 17, 2007 at 10:07:09AM -0300, Jorge Arellano Cid wrote:
Please note that the enter key is selecting text instead of adding a new line...
It's in the TO DO, along with the need for a scroller (and thanks for the example page, BTW). I have some tweaks and cleanups to submit first.
Just tried to use the TextEditor widget from fltk (see test/input.cxx in the fltk tarball). It has scrollbar support built in and perhaps other useful stuff. Unfortunately it crashes on division by zero here... Regards, Johannes
Regards,
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Mon, Dec 17, 2007 at 04:44:01PM +0100, Johannes Hofmann wrote:
Just tried to use the TextEditor widget from fltk (see test/input.cxx in the fltk tarball). It has scrollbar support built in and perhaps other useful stuff. Unfortunately it crashes on division by zero here...
Same here (or rather it's a floating point error which I assume is a division by zero). How annoying, especially as it's clearly the right widget to use and would give us scrolling for free. Guess I'll be recompiling FLTK2 with debugging next... Regards, Jeremy Henty
On Tue, Dec 18, 2007 at 07:11:27AM +0000, Jeremy Henty wrote:
On Mon, Dec 17, 2007 at 04:44:01PM +0100, Johannes Hofmann wrote:
Just tried to use the TextEditor widget from fltk ... Unfortunately it crashes on division by zero here...
Same here
The problem is that "editor->draw ()" gets called before "editor->layout ()", so the maxsize_ member is 0. I can fix the crash by explicitly calling "editor->layout ()" after creating the TextEditor and attaching its TextBuffer , but then the editor comes up inactive; it displays nothing and responds to nothing, although it will still submit its initial text when the form is activated. I think there must be something about the way DW creates widgets that means the TextEditor isn't being managed properly; it can't be right that layout() is not being called. Thoughts? Jeremy Henty
On Tue, Dec 18, 2007 at 08:28:45AM +0000, Jeremy Henty wrote:
On Tue, Dec 18, 2007 at 07:11:27AM +0000, Jeremy Henty wrote:
On Mon, Dec 17, 2007 at 04:44:01PM +0100, Johannes Hofmann wrote:
Just tried to use the TextEditor widget from fltk ... Unfortunately it crashes on division by zero here...
Same here
The problem is that "editor->draw ()" gets called before "editor->layout ()", so the maxsize_ member is 0. I can fix the crash by explicitly calling "editor->layout ()" after creating the TextEditor and attaching its TextBuffer , but then the editor comes up inactive; it displays nothing and responds to nothing, although it will still submit its initial text when the form is activated.
I think there must be something about the way DW creates widgets that means the TextEditor isn't being managed properly; it can't be right that layout() is not being called.
Thoughts?
Please try this patch: diff -r 3d6ba14ceb96 dw/fltkviewport.cc --- a/dw/fltkviewport.cc Tue Dec 18 16:42:42 2007 +0100 +++ b/dw/fltkviewport.cc Tue Dec 18 16:47:31 2007 +0100 @@ -154,6 +154,7 @@ void FltkViewport::layout () { theLayout->viewportSizeChanged (this, w(), h()); adjustScrollbarsAndGadgetsAllocation (); + Group::layout (); } void FltkViewport::draw_area (void *data, const Rectangle& cr )
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Tue, Dec 18, 2007 at 04:48:27PM +0100, Johannes Hofmann wrote:
On Tue, Dec 18, 2007 at 08:28:45AM +0000, Jeremy Henty wrote:
I think there must be something about the way DW creates widgets that means the TextEditor isn't being managed properly; it can't be right that layout() is not being called.
Thoughts?
Please try this patch:
Success! Well, sort of: Dillo works fine, but test/dw-ui-test is broken. Here's the TextEditor patch anyway. It depends on my previous patch to remove the special behaviour of the <Enter>. Johannes' patch in the previous message is also necessary for things to work. Now we just have to fix test/dw-ui-test , but I think that's probably a lower priority than completing Dillo's functionality. Regards, Jeremy Henty diff -pru -- dw2-ref/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2-ref/dw/fltkui.cc 2007-12-18 17:22:38.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-12-18 17:31:03.000000000 +0000 @@ -30,7 +30,7 @@ #include <fltk/Group.h> #include <fltk/Input.h> #include <fltk/SecretInput.h> -#include <fltk/MultiLineInput.h> +#include <fltk/TextEditor.h> #include <fltk/RadioButton.h> #include <fltk/CheckButton.h> #include <fltk/Choice.h> @@ -533,7 +533,7 @@ FltkMultiLineTextResource::FltkMultiLine FltkSpecificResource <dw::core::ui::MultiLineTextResource> (platform), numCols(cols), numRows(rows) { - initText = NULL; + buffer = new ::fltk::TextBuffer; editable = false; init (platform); @@ -541,27 +541,18 @@ FltkMultiLineTextResource::FltkMultiLine FltkMultiLineTextResource::~FltkMultiLineTextResource () { - if (initText) - delete initText; + delete buffer; } ::fltk::Widget *FltkMultiLineTextResource::createNewWidget (core::Allocation *allocation) { - ::fltk::MultiLineInput *input = - new ::fltk::MultiLineInput (allocation->x, allocation->y, - allocation->width, - allocation->ascent + allocation->descent); - - if (viewsAndWidgets->isEmpty ()) { - // First widget created, attach the set text. - if (initText) - input->value (initText); - } else - input->value - (((::fltk::MultiLineInput*)viewsAndWidgets->getFirst()->widget)->value ()); - - return input; + ::fltk::TextEditor *text = + new ::fltk::TextEditor (allocation->x, allocation->y, + allocation->width, + allocation->ascent + allocation->descent); + text->buffer (buffer); + return text; } void FltkMultiLineTextResource::sizeRequest (core::Requisition *requisition) @@ -586,23 +577,12 @@ void FltkMultiLineTextResource::sizeRequ const char *FltkMultiLineTextResource::getText () { - if (viewsAndWidgets->isEmpty ()) - return initText; - else - return ((::fltk::MultiLineInput*)viewsAndWidgets->getFirst()->widget)->value (); + return buffer->text (); } void FltkMultiLineTextResource::setText (const char *text) { - if (initText) - delete initText; - initText = strdup (text); - - for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); - it.hasNext(); ) { - ViewAndWidget *viewAndWidget = it.getNext (); - ((::fltk::MultiLineInput*)viewAndWidget->widget)->value (initText); - } + buffer->text (text); } bool FltkMultiLineTextResource::isEditable () diff -pru -- dw2-ref/dw/fltkui.hh dw2-cur/dw/fltkui.hh --- dw2-ref/dw/fltkui.hh 2007-12-18 17:22:38.000000000 +0000 +++ dw2-cur/dw/fltkui.hh 2007-12-18 17:26:59.000000000 +0000 @@ -7,6 +7,7 @@ #include <fltk/Button.h> #include <fltk/Menu.h> +#include <fltk/TextBuffer.h> namespace dw { namespace fltk { @@ -317,7 +318,7 @@ class FltkMultiLineTextResource: public FltkSpecificResource <dw::core::ui::MultiLineTextResource> { private: - const char *initText; + ::fltk::TextBuffer *buffer; bool editable; int numCols, numRows;
On Tue, Dec 18, 2007 at 05:44:30PM +0000, Jeremy Henty wrote:
On Tue, Dec 18, 2007 at 04:48:27PM +0100, Johannes Hofmann wrote:
On Tue, Dec 18, 2007 at 08:28:45AM +0000, Jeremy Henty wrote:
I think there must be something about the way DW creates widgets that means the TextEditor isn't being managed properly; it can't be right that layout() is not being called.
Thoughts?
Please try this patch:
Success! Well, sort of: Dillo works fine, but test/dw-ui-test is broken. Here's the TextEditor patch anyway. It depends on my previous patch to remove the special behaviour of the <Enter>. Johannes' patch in the previous message is also necessary for things to work.
Now we just have to fix test/dw-ui-test , but I think that's probably a lower priority than completing Dillo's functionality.
Ooops, you are right! There is a problem with my proposed fix. When we call Group::layout (), the Group code starts to reposition / resize the widgets. But we want to control the layout on our own. Please try this instead: diff -r 3d6ba14ceb96 dw/fltkviewport.cc --- a/dw/fltkviewport.cc Tue Dec 18 16:42:42 2007 +0100 +++ b/dw/fltkviewport.cc Tue Dec 18 22:56:50 2007 +0100 @@ -154,6 +154,16 @@ void FltkViewport::layout () { theLayout->viewportSizeChanged (this, w(), h()); adjustScrollbarsAndGadgetsAllocation (); + + for(Iterator <TypedPointer < ::fltk::Widget> > it + = canvasWidgets->iterator (); + it.hasNext (); ) { + ::fltk::Widget *widget = it.getNext()->getTypedValue (); + + if (widget->layout_damage ()) { + widget->layout (); + } + } } Regards, Johannes PS: I start thinking that fltkviewbase should not inherit from Group at all. fltkviewbase hardly uses any functionality from Group anymore.
Regards,
Jeremy Henty
diff -pru -- dw2-ref/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2-ref/dw/fltkui.cc 2007-12-18 17:22:38.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-12-18 17:31:03.000000000 +0000 @@ -30,7 +30,7 @@ #include <fltk/Group.h> #include <fltk/Input.h> #include <fltk/SecretInput.h> -#include <fltk/MultiLineInput.h> +#include <fltk/TextEditor.h> #include <fltk/RadioButton.h> #include <fltk/CheckButton.h> #include <fltk/Choice.h> @@ -533,7 +533,7 @@ FltkMultiLineTextResource::FltkMultiLine FltkSpecificResource <dw::core::ui::MultiLineTextResource> (platform), numCols(cols), numRows(rows) { - initText = NULL; + buffer = new ::fltk::TextBuffer; editable = false;
init (platform); @@ -541,27 +541,18 @@ FltkMultiLineTextResource::FltkMultiLine
FltkMultiLineTextResource::~FltkMultiLineTextResource () { - if (initText) - delete initText; + delete buffer; }
::fltk::Widget *FltkMultiLineTextResource::createNewWidget (core::Allocation *allocation) { - ::fltk::MultiLineInput *input = - new ::fltk::MultiLineInput (allocation->x, allocation->y, - allocation->width, - allocation->ascent + allocation->descent); - - if (viewsAndWidgets->isEmpty ()) { - // First widget created, attach the set text. - if (initText) - input->value (initText); - } else - input->value - (((::fltk::MultiLineInput*)viewsAndWidgets->getFirst()->widget)->value ()); - - return input; + ::fltk::TextEditor *text = + new ::fltk::TextEditor (allocation->x, allocation->y, + allocation->width, + allocation->ascent + allocation->descent); + text->buffer (buffer); + return text; }
void FltkMultiLineTextResource::sizeRequest (core::Requisition *requisition) @@ -586,23 +577,12 @@ void FltkMultiLineTextResource::sizeRequ
const char *FltkMultiLineTextResource::getText () { - if (viewsAndWidgets->isEmpty ()) - return initText; - else - return ((::fltk::MultiLineInput*)viewsAndWidgets->getFirst()->widget)->value (); + return buffer->text (); }
void FltkMultiLineTextResource::setText (const char *text) { - if (initText) - delete initText; - initText = strdup (text); - - for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); - it.hasNext(); ) { - ViewAndWidget *viewAndWidget = it.getNext (); - ((::fltk::MultiLineInput*)viewAndWidget->widget)->value (initText); - } + buffer->text (text); }
bool FltkMultiLineTextResource::isEditable () diff -pru -- dw2-ref/dw/fltkui.hh dw2-cur/dw/fltkui.hh --- dw2-ref/dw/fltkui.hh 2007-12-18 17:22:38.000000000 +0000 +++ dw2-cur/dw/fltkui.hh 2007-12-18 17:26:59.000000000 +0000 @@ -7,6 +7,7 @@
#include <fltk/Button.h> #include <fltk/Menu.h> +#include <fltk/TextBuffer.h>
namespace dw { namespace fltk { @@ -317,7 +318,7 @@ class FltkMultiLineTextResource: public FltkSpecificResource <dw::core::ui::MultiLineTextResource> { private: - const char *initText; + ::fltk::TextBuffer *buffer; bool editable; int numCols, numRows;
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Tue, Dec 18, 2007 at 11:01:01PM +0100, Johannes Hofmann wrote:
Ooops, you are right! There is a problem with my proposed fix. When we call Group::layout (), the Group code starts to reposition / resize the widgets.
Yes, after posting I noticed that resizing the browser window made the embedded widgets slide around the page. Very annoying.
Please try this instead:
Looks good! Both dillo and test/dw-ui-test work fine, with no moving widgets. Hopefully we've cracked it. I'm still surprised that none of these problems showed up until we tried to use a FLTK TextEditor. Is it possible we're working around some bug in TextEditor, or were we just lucky up until now? Regards, Jeremy Henty
On Wed, Dec 19, 2007 at 10:53:02AM +0000, Jeremy Henty wrote:
On Tue, Dec 18, 2007 at 11:01:01PM +0100, Johannes Hofmann wrote:
Ooops, you are right! There is a problem with my proposed fix. When we call Group::layout (), the Group code starts to reposition / resize the widgets.
Yes, after posting I noticed that resizing the browser window made the embedded widgets slide around the page. Very annoying.
Please try this instead:
Looks good! Both dillo and test/dw-ui-test work fine, with no moving widgets. Hopefully we've cracked it.
Please test this solution and send me a full patch once it passes. -- Cheers Jorge.-
On Wed, Dec 19, 2007 at 10:53:02AM +0000, Jeremy Henty wrote:
On Tue, Dec 18, 2007 at 11:01:01PM +0100, Johannes Hofmann wrote:
Please try this instead:
Looks good! Both dillo and test/dw-ui-test work fine, with no moving widgets. Hopefully we've cracked it.
Spoke too soon! I have a dillo page with a link to a test page with a form. If I middle-click on the link then the test page comes up blank. I have to hit reload before the form widgets appear. Left-clicking the link works OK. I hope this is simple to fix! Regards, Jeremy Henty
On Wed, Dec 19, 2007 at 02:22:26PM +0000, Jeremy Henty wrote:
I have a dillo page with a link to a test page with a form. If I middle-click on the link then the test page comes up blank. I have to hit reload before the form widgets appear. Left-clicking the link works OK. I hope this is simple to fix!
Follow-up: this bug only appears when the window is large enough to fit the whole form in vertically. If I resize the window vertically so that it will be too small to hold the whole form, then middle-click the link, the new window displays the form properly. I guess the widgets aren't getting marked as damaged if they all fit in the new window, so they don't display themselves? Regards, Jeremy Henty
Hi, attached is a new patch. Please test it carefully instead of my initial one. * It moves the call to layout from FltkViewport to FltkWidgetView. This is just a cleanup - no functional change * FltkViewbase now call Group::draw() always if DAMAGE_CHILD is set even if other flags are set too. That seems to fix the issue you have noticed when opening a window with the middle mouse button. Cheers, Johannes On Wed, Dec 19, 2007 at 03:11:55PM +0000, Jeremy Henty wrote:
On Wed, Dec 19, 2007 at 02:22:26PM +0000, Jeremy Henty wrote:
I have a dillo page with a link to a test page with a form. If I middle-click on the link then the test page comes up blank. I have to hit reload before the form widgets appear. Left-clicking the link works OK. I hope this is simple to fix!
Follow-up: this bug only appears when the window is large enough to fit the whole form in vertically. If I resize the window vertically so that it will be too small to hold the whole form, then middle-click the link, the new window displays the form properly.
I guess the widgets aren't getting marked as damaged if they all fit in the new window, so they don't display themselves?
Regards,
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Wed, Dec 19, 2007 at 07:28:44PM +0100, Johannes Hofmann wrote:
attached is a new patch. Please test it carefully instead of my initial one.
Not fixed yet. :-( The bug appears to be sporadic now: sometimes a middle-click brings up a blank page, sometimes not. I *think* that a left-click still always works. NB: the test page includes an input widget and it is affected too, so this is not AFAICT specific to the FLTK TextEditor. Can you reproduce this at all? Maybe it's affected by the window manager? I'm running Linux 2.6.23 + X windows 7.1 + icewm. Jeremy Henty
On Wed, Dec 19, 2007 at 09:41:20PM +0000, Jeremy Henty wrote:
On Wed, Dec 19, 2007 at 07:28:44PM +0100, Johannes Hofmann wrote:
attached is a new patch. Please test it carefully instead of my initial one.
Not fixed yet. :-( The bug appears to be sporadic now: sometimes a middle-click brings up a blank page, sometimes not. I *think* that a left-click still always works. NB: the test page includes an input widget and it is affected too, so this is not AFAICT specific to the FLTK TextEditor.
Can you reproduce this at all? Maybe it's affected by the window manager? I'm running Linux 2.6.23 + X windows 7.1 + icewm.
Yes, I could reproduce it - sporadically. But I no longer can with my change... I will keep on trying. Johannes
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Thu, Dec 20, 2007 at 07:12:56PM +0100, Johannes Hofmann wrote:
On Wed, Dec 19, 2007 at 09:41:20PM +0000, Jeremy Henty wrote:
Not fixed yet. :-( The bug appears to be sporadic now: sometimes a middle-click brings up a blank page, sometimes not. I *think* that a left-click still always works. NB: the test page includes an input widget and it is affected too, so this is not AFAICT specific to the FLTK TextEditor.
Can you reproduce this at all? Maybe it's affected by the window manager? I'm running Linux 2.6.23 + X windows 7.1 + icewm.
Yes, I could reproduce it - sporadically. But I no longer can with my change... I will keep on trying.
I believe I have fixed it. FltkViewport::{scrollDX,scrollDY} were not being initialised. This explains why sometimes the form rendered but displaced vertically (which I forgot to mention). I imagine the blank pages were due to the same bug scrolling the form right off the page. I'll post the fix and the complete textarea patch to new threads: this is getting confusing! Johannes, you'll need to tell me which of your viewport patches I should use; it's possible that once this scrolling fix is committed some of your earlier efforts may turn out to be sufficient. Regards, Jeremy Henty
On Wed, Dec 19, 2007 at 02:22:26PM +0000, Jeremy Henty wrote:
On Wed, Dec 19, 2007 at 10:53:02AM +0000, Jeremy Henty wrote:
On Tue, Dec 18, 2007 at 11:01:01PM +0100, Johannes Hofmann wrote:
Please try this instead:
Looks good! Both dillo and test/dw-ui-test work fine, with no moving widgets. Hopefully we've cracked it.
Spoke too soon! I have a dillo page with a link to a test page with a form. If I middle-click on the link then the test page comes up blank. I have to hit reload before the form widgets appear. Left-clicking the link works OK. I hope this is simple to fix!
I will look at this. But I just noticed another subtle issue when using TextEditor in forms: When you leave a page that has a textarea field you get a double free(). The TextBuffer is deleted first, then the TextEditor widgets are deleted and these access member methods of of the TextBuffer in their destructors. I have no idea yet how to fix this. Perhaps we can disassociate the TextBuffer from the TextEditor widgets in the FltkMultiLineTextResource destructor before deleting it? Cheers, Johannes
Regards,
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Wed, Dec 19, 2007 at 06:34:19PM +0100, Johannes Hofmann wrote:
When you leave a page that has a textarea field you get a double free(). The TextBuffer is deleted first, then the TextEditor widgets are deleted and these access member methods of of the TextBuffer in their destructors.
Ouch! Yes, since the derived class manages the buffer and the superclass manages the widgets C++ insists on deleting the buffer first.
I have no idea yet how to fix this. Perhaps we can disassociate the TextBuffer from the TextEditor widgets in the FltkMultiLineTextResource destructor before deleting it?
I think we must, since we have no way of postponing the deletion of the buffer. Here's the patch. Jeremy Henty diff -pru -- dw2-ref/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2-ref/dw/fltkui.cc 2007-12-19 14:13:25.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-12-19 21:10:16.000000000 +0000 @@ -541,6 +541,11 @@ FltkMultiLineTextResource::FltkMultiLine FltkMultiLineTextResource::~FltkMultiLineTextResource () { + for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); + it.hasNext(); ) { + ViewAndWidget *viewAndWidget = it.getNext (); + ((::fltk::TextEditor *) viewAndWidget->widget)->buffer (0); + } delete buffer; }
On Wed, Dec 19, 2007 at 09:35:01PM +0000, Jeremy Henty wrote:
On Wed, Dec 19, 2007 at 06:34:19PM +0100, Johannes Hofmann wrote:
When you leave a page that has a textarea field you get a double free(). The TextBuffer is deleted first, then the TextEditor widgets are deleted and these access member methods of of the TextBuffer in their destructors.
Ouch! Yes, since the derived class manages the buffer and the superclass manages the widgets C++ insists on deleting the buffer first.
I have no idea yet how to fix this. Perhaps we can disassociate the TextBuffer from the TextEditor widgets in the FltkMultiLineTextResource destructor before deleting it?
I think we must, since we have no way of postponing the deletion of the buffer. Here's the patch.
Jeremy Henty
diff -pru -- dw2-ref/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2-ref/dw/fltkui.cc 2007-12-19 14:13:25.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-12-19 21:10:16.000000000 +0000 @@ -541,6 +541,11 @@ FltkMultiLineTextResource::FltkMultiLine
FltkMultiLineTextResource::~FltkMultiLineTextResource () { + for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); + it.hasNext(); ) { + ViewAndWidget *viewAndWidget = it.getNext (); + ((::fltk::TextEditor *) viewAndWidget->widget)->buffer (0); + } delete buffer; }
Yes, fixed! Regards, Johannes
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org