Recent

Author Topic: Debug in Lazarus : WMLButtonUp error (RESOLVED)  (Read 585 times)

Nono Reading Activity

  • New Member
  • *
  • Posts: 46
Debug in Lazarus : WMLButtonUp error (RESOLVED)
« on: February 02, 2024, 08:03:49 am »
Hello
i have that message
can someone give me a hint what i should check ? i don't remember changing something linked to Mouse Up, but i could by mistake ^^;
« Last Edit: February 02, 2024, 01:03:33 pm by Nono Reading Activity »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Debug in Lazarus : WMLButtonUp error
« Reply #1 on: February 02, 2024, 10:22:15 am »
Maybe you have something like
Code: Pascal  [Select][+][-]
  1. Button1.Destroy;
Code: Pascal  [Select][+][-]
  1. Sender.Free;

in a ButtonClick event?

In any event, if you free any component, you must make sure that you do not free the component that is the target of the event itself.

The easiest way is to use "ReleaseComponent" which will free the component, once the event is over. You can set the component to "visible := false" in the event.


Nono Reading Activity

  • New Member
  • *
  • Posts: 46
Re: Debug in Lazarus : WMLButtonUp error (RESOLVED)
« Reply #2 on: February 02, 2024, 01:05:43 pm »
thanks, it helped me a lot.
i was using Destroy to close a Form and i replaced it with Close and i don't have the error.
what's bug me if the code is months old and it start crashing today ^^;

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Debug in Lazarus : WMLButtonUp error (RESOLVED)
« Reply #3 on: February 02, 2024, 01:14:19 pm »
If you destroy the form/component, and other code (such as the calling code in your case) is still using that component, then you have a "dangling pointer"

Than means your other code access the content of memory that has been freed. The effects of that will be random.

Because if any unrelated code did any memory alloc/free, then the freed mem of your dangling pointer could have been re-used, and the content of that memory changed.
If the dangling pointer accesses that memory, then it depends on the content.
Maybe there is code like "if dangling_object.field1 <> 42 then do_something_that_crash()". It wont crash, unless there is a 42. And any other code might place the 42 there.

 

TinyPortal © 2005-2018