I wonder if this is pertinent to your issue: viewtopic.php?f=2&t=15729#p46710

Another approach is to use an edit control and set the Visible property to False. That control will accumulate the keys pressed, so you can either use that "history" or clear the edit control after each key press.

Controls capture the key actions before the form can act on them. If you delete all controls on the form which might capture a key press (including OK and Cancel buttons) then you can see that the form itself can capture the keystrokes. I haven't worked out how to handle having certain key actions b...

Thomas, thank you very much for looking into this.

I guess at this point it is sufficient to label this behavior "unfathomable" so that I can stop doubting my sanity.

Does this misbehavior also occur with VIP-9 ?

Here is a scenario that will raise the above exception with seeming healthy code: Build a 32 bit application with 64 bit IDE: the application executes OK. When I try to run with debugger I get a message asking to switch to 32 bit IDE. I accept the switch to 32 bit IDE. Run application without debugg...

I wonder if there is an inconsistency in building the application because the code below will either always work on one build or always raise an exception in another build. I force recompilation by just inserting a few spaces to the source .PRO file. It seems to occur randomly in 32 & 64 bit compila...

I didn't understand that about onPaint. For testing purposes, the only predicate call in onPaint was processEvents(). My thought was that it would be the last predicate call in onPaint if I were to use in practice. When initially testing using the debugger (VP8, Win32) I noticed that the Source wind...

Hmmm ... there are many things happening in GUI event processing that I don't fully understand yet. :o If I call vpi::processEvents() at the end of the onPaint/3 call and put it after the clientWin_putClipboardBMP(Source) call in onMouseUp/4 like below, the code works OK. ... gfxImageIO::clientWin_p...

I am trying to copy an image of a form's client window to the Windows clipboard. What is the difference in how these two event handlers receive the window handle? (Of course, I wouldn't normally try to get a snapshot of the client window -- that is just there for debugging.) In both predicates Sourc...

Thanks, Tonton -- you made me start thinking of things to do that I hadn't planned to think about!

"I suspect you think the Rectangle in a printResponder is something different than what it is. This is what it is: The part of the client rectangle that needs to be repainted. " Ahhh ... thank you very much! You are right, I erroneously assumed that the Rectangle in the paintResponder was the client...

OK, here it is as a VP 8.02 project. The problem is how I am handling GDIP in the onPaint/3 event in graphDisplayForm.pro (Line 44). Other "empty" forms behave normally. My idea is that the rugPainter object stores the graphics information on creation and Rug:paint() uses that information to draw th...

VIP Version 7.502

I've tested it several different ways, using vipCommonDialogs type dialogs and my own small dialogs and forms.

How do I make form windows repaint themselves when another form window passes over them? Consider two scenarios: 1. Open form FormF then open dialog DlgD. If I move DlgD around on top of FormF then FormF repaints as expected. 2. Open two forms, FormA and FormB. If I move FormA around on top of FormB...

Here's a suggestion from someone who knows nothing about the complexity of your project: Create an internal fact database in dialogA and populate it with information to control what the user needs to see or wants to revisit. Put human-readable strings in the database that can be used to populate a l...