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...

"so many instances of B, maximizing and comparing the dialogs becomes tedious." Yes ... but you could put the B-dialog identifiers into a database (or a list in a mutable variable) in the A-dialog as you create them. This might not correspond to what you are trying to achieve, but have you consider...

This might have an effect you desire -- just make dialogB invisible (or minimized) when you press Cancel. Put this in dialogB: predicates onCancelClick : button::clickResponder. clauses onCancelClick(_Source) = button::noAction :- This:setState([vpiDomains::wsf_Invisible]). You will need to keep tra...

Take a look at this in the IDE help: vpi::winBringToTop/1 winBringToTop : (vpiDomains::windowHandle WindowHandle) language c. Brings the window WindowHandle to the front of the screen. Description Use the winBringToTop predicate to uncover any window that is partially or completely obscured by other...