Chris,
Wouldn't the form need to be repainted when the box is moved?
Now, if the info box was to show up outside of the bounds of the form
initially, this could work. Or am I missing something?
Cheers, bob
> On Dec 22, 2019, at 11:31 AM, chris burke wrote:
>
> Right, but you can add a try/ca
Right, but you can add a try/catch while developing. In production, you
should make sure your painting works.
The wd paint handler is called when Qt requests a paint instruction, and
that needs to be given, i.e. the paint handler needs to return. If the
paint handler hangs, then so does Qt.
One t
Lol. Case in point. Sometimes I just hit the wrong key and things go bad.
What I was going to say is that often I have an error that forces me to
kill the IDE,
then I reload everything, and like a complete idiot hit the run button
again out of habit.
So I only get to fix the problem on the third t
I get that try / catch works, but I don't think it's a good answer.
Exception handling should be for things that might fail because of external
issues (files not existing, bad input, etc).
It shouldn't be a discipline you have to adopt just in case you make a typo.
Usually when this happens, it's
Would it help to use try/catch in the paint handler? For example, in the
below, try resizing the window. Each time the paint handler is called the
error is written to the session and the image painted a new color:
wd 'reset'
wd 'pc win0 closeok; pn "debug me"'
wd 'cc img isigraph'
wd 'pshow'
win0_
