MartinC
asked on
Can a Button Delete Itself?
I have a button that has been created on the fly, which when clicked, executes a
procedure (say UpdateContent) which changes the content of a database then
destroys the button itself, then recalls the procedure (say LoadPage)
that created the button in the first place. It works OK except that it
brings up an error message whenever the code is run (AFTER the destroy
and recall functions of LoadPage have been executed) when the
line-by-line handling returns back to UpdateContent for the final end.
This is presumably because the button that called the procedure no
longer exists. Is there any simple way around this?
procedure (say UpdateContent) which changes the content of a database then
destroys the button itself, then recalls the procedure (say LoadPage)
that created the button in the first place. It works OK except that it
brings up an error message whenever the code is run (AFTER the destroy
and recall functions of LoadPage have been executed) when the
line-by-line handling returns back to UpdateContent for the final end.
This is presumably because the button that called the procedure no
longer exists. Is there any simple way around this?
moorhouselondon
If in the button click procedure you make a call to the OnClick event of a hidden button on the form, then I reckon that, within the hidden button procedure you will be able to delete the original button. You can easily identify which button Sent the click by using Tag.
When you make the call to the OnClick event of the other button the program will start execution of that code which then deletes the first button. When the OnClick is completed however, it will return to the place where it was called from... the OnClick of the button you just deleted :)
One way to do this is to use PostMessage to post a mouse click message...
PostMessage(SecondButton.H
PostMessage(SecondButton.H
That way the OnCLick of the first button will be completed first after which the onClick of the 2nd button will be executed.
Hope this helps,
D2.
One way to do this is to use PostMessage to post a mouse click message...
PostMessage(SecondButton.H
PostMessage(SecondButton.H
That way the OnCLick of the first button will be completed first after which the onClick of the 2nd button will be executed.
Hope this helps,
D2.
ASKER
morhouselondon: I'm afraid your solution just passes the buck one level higher. I tried a similar method at first, having the button's OnClick call a separate procedure entirely, but as wavget pointed out, eventually the code returns to the calling procedure just to do the "end" line, whereupon it falls over its own feet.
wavget: that solution looks kinda ugly ... my own ugly solution was to have the button do UpdateContent then just set a boolean called bCleanup to true, without calling the LoadPage. Then I'd use the timer to sweep through every second looking for bCleanup = true, do the destroy and recall functions of LoadPage, and reset bCleanup to false. I have the timer on there already anyway as the application has a running clock in it, so there won't be much additional overhead resource-wise. But it is not a pretty solution ... can lead to problems later. Similarly, I'd rather not muck about with the actual comp's handling of the clicks if I can help it.
Anyone got a more elegant solution?
wavget: that solution looks kinda ugly ... my own ugly solution was to have the button do UpdateContent then just set a boolean called bCleanup to true, without calling the LoadPage. Then I'd use the timer to sweep through every second looking for bCleanup = true, do the destroy and recall functions of LoadPage, and reset bCleanup to false. I have the timer on there already anyway as the application has a running clock in it, so there won't be much additional overhead resource-wise. But it is not a pretty solution ... can lead to problems later. Similarly, I'd rather not muck about with the actual comp's handling of the clicks if I can help it.
Anyone got a more elegant solution?
Hmmm I dynamically delete panels on a form, but thinking about it I'm doing that from a popup menu, which is outside the scope of "pulling the rug from under oneself".
I suppose my suggestion of creating a hidden button could have been simplified to saying: why not just Hide the original button and reuse it when necessary? That depends on whether there is the possibility that multiple buttons will be created which need to be hidden/deleted.
The idea of having a timed cleanup sweep sounds good.
I suppose my suggestion of creating a hidden button could have been simplified to saying: why not just Hide the original button and reuse it when necessary? That depends on whether there is the possibility that multiple buttons will be created which need to be hidden/deleted.
The idea of having a timed cleanup sweep sounds good.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hmmm, sorry, I forgot I had left this question open, so I'll close it off now. I suspect my strategy was flawed from the outset and certainly the solutions presented above seem rather open to things going wrong later. So I have bitten the bullet and coded the database handling and the screen reconstruction to occur separately i.e. I never recall the LoadPage procedure that created the button in the first place, I just duplicate in the UpdateContent procedure some of the LoadPage handing code for screen generation that I had hoped to store in a single procedure.
Of the solutions above, rllibby's provided a comprehensive synopsis of the insoluble aspects of the problem which led me to make the decision to abandon the plan, so points to him. Thanks to others as well.
Of the solutions above, rllibby's provided a comprehensive synopsis of the insoluble aspects of the problem which led me to make the decision to abandon the plan, so points to him. Thanks to others as well.