cancel
Showing results for 
Search instead for 
Did you mean: 

Response window suddenly invisible - Windows Vista

Former Member
0 Kudos

Suddenly today we were alerted to a problem where our application "seems to hang" during an operation.  We figured out what is happening: namely a response window is being "displayed", however it is not visible.  When the user presses <escape> the invisible response window closes and the application is responsive again. 

This problem only seems to occur on Windows Vista, and we have reproduced it ourselves.  It happens in versions of our PB Classic application built using PB 12.5.2 (5006), AND PB 10.

Interestingly other response windows in our application display fine.  The notable aspect of the problem response window is that it is somewhat larger. 

Also interestingly we witnessed the EXACT same problem a few years ago when our application was published using Windows Terminal Services.  Time passed and this problem under Windows Terminal Services went away.  Citrix terminal services has never been a problem. 

We are sure the response window is invisible rather than submerged under another window because we can "move" it by <alt>+<space> to get the window menu, then click "Move" and use the arrow keys. 

At this point we can only speculate that a Windows Update has caused this.  We are talking about an installed program behaving fine today, and not tomorrow.  Nothing changed, and as mentioned above, we have reproduced it.

Feedback or suggestions are welcome!

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

We had a similar issue recently with Responses and Vista

A colleague found out it was an ATI drivers update that caused the mess.

Apparently the driver updated set the screen refresh frenquency too high (75hz instead of 60hz)

Setting the frequency back to 60hz fixed the problem.

Former Member
0 Kudos

Checked that, the refresh rate on the Vista PC I could replicate it on was already 60hz.

Former Member
0 Kudos

Same result as Dan - our test Vista computer was already refreshing at 60hz.  However changing the Theme to "Windows Classic" fixed the problem for us and our customer too.

Former Member
0 Kudos

We are having the same problem with the main window of one of our apps, with about 4 users reporting it so far. I have established that the two of them that I have been able to investigate are both on Windows Vista Home Premium. The window background is Buttonface.

Switching the users from the Windows Vista theme to the Windows Classic theme made the problem go away.

I think this must be something due to a Windows Update, because it just started about 2 days ago, just like the original poster said. The main window with the problem does NOT have any invisible objects on it, nor are any set to invisible during the opening of the window in normal operation.

Would still appreciate any further thoughts that would allow them to go back to the Windows Vista theme.

Former Member
0 Kudos

Can you please clarify whether your affected window is a Response Window (modal)?

It sounds like not.  We have only observed the problem on response windows, and certainly hope no other window type is affected.

Former Member
0 Kudos

Hi Dan;

  W10 should fix it ....

OK .. Could not resist that one .... <my bad>

Regards ... Chris

Former Member
0 Kudos

Nope, in our case it's a Main window - the program's main window in fact.

Former Member
0 Kudos

Har de har har Chris. You would not believe how badly installing a pre-release of Windows 10 messed up my travel computer recently. But that's very much off-line this thread and in fact this entire forum.

Former Member
0 Kudos

Maybe off-line but ... a good story I bet!  

Former Member
0 Kudos

Further to this, following up the leads above about invisible objects, I checked and there are no invisible objects on our main window that is displaying this problem. However, there was a column on a DW displayed on the window that becomes invisible (through a property expression) in certain circumstances. I tested it with that column NOT becoming invisible, but the same problem persists.

So at this point we are still stuck with the only fix being to switch to the Windows Classic theme.

Former Member
0 Kudos

Are you sure there is no code in the window or invoked by the window that can set a control to invisible?  You sound quite through, but all I can suggest is a text search on ".visible" and see if something pops up.

FWIW - our app has a lot of main and pop-up windows with invisible controls, and so far none of these windows have "disappeared" on Vista. 

This is certainly an unpleasant type of problem!

Former Member
0 Kudos

OK, turns out the main window is inherited from another window that is responsible for resizing and re-positioning (to match the last run of the program) on startup. To fix a weird display bug on XP, that window sets itself to invisible before the resizing and repositioning, and sets itself back to visible after that. (That's all in the open event, so before the window is even really displayed.) Obviously that final call to set it visible again is failing on some themes.

Former Member
0 Kudos

OMG ... What idiot coded it that way versus using the SetReDraw () method!  

Former Member
0 Kudos

I noticed differences in the window open/resize processing when going from PB10 to PB10.5.

arnd_schmidt
Active Contributor
0 Kudos

outch. I got to review my old sources...

Former Member
0 Kudos

I'm the "idiot" that coded it that way. We sell to churches and charities, who have a lot of old computers, including XP. And we found that without that set invisible before the resize and reposition of some windows, and set back visible afterwards, on XP some such windows would leave "shadows" of their pre-resize borders, including the title bar, on the desktop and/or overlapping the main window! I could try it with SetRedraw instead and see whether it resolves the problem on Vista, but I'm not sure I can reliably reproduce the problem on the one XP computer I have enough to be sure I didn't reintroduce it.

Former Member
0 Kudos

I knew your were they guy as soon as I posted that. 

  Don't worry, I still revise my older framework code and see some crappy implementation from over a decade ago and say to my other developers (me, myself and I) ... what idiot wrote that? Of course, the answer is me ... LOL! 

FWIW:I have never had this issue on XP or any other Windows O/S version. However, I handle things like this in my framework as follows:

1) Never code anything in a Constructor or Open event

2) Always use the PostOpen or PostConstructor event to implement initialization code

3) If you are resizing, make the Window invisible in the painter (aka PBL)

4) Resize the window in the PostOpen - then make it visible when all initializations have been completed.

HTH

Former Member
0 Kudos

Dan,

Rather than setting the window invisible in the ancestor, you might try opening it in with coordinates of -1000, -1000 (or similar) so that it does not appear on screen to the user.  Then move it to the specific coordinates based on the user settings.  This way you are never setting the visible/not visible property.

Matt

Former Member
0 Kudos

I'm doing the set invisible then visible because it fixes a bug we observed XP, where "shadows" of parts of the window at previous sizes and positions were left on the screen. So I'm not inclined to remove it in case that bug comes back.

I've also tried various version of Chris Pollach's suggestions, where the invisible is set in the painter, and the visible is only set in a postopen event. Everything I tried either didn't work, or bizarrely made the compiled version of the app crash in either Vista or my current development machine (Windows 7), usually either when opening the 2nd resizable window or when closing that window.

So I give up. I will just stick with the solution of switching to the Windows Classic theme, for the few users still using Vista who have noticed the problem.

Former Member
0 Kudos

We have found a fix to this problem:

One of the windows had a visual user object on it that was statically set to Invisible.  We removed this object and commented out referencing code, and the window became visible again.

The other window had a number of code statements rendering visual controls invisible.  At least some of this code executed before the window rendered.  We commented out these lines of code and the window became visible again.

Again - this problem has only been observed on Windows Vista, and only started happening within the past few days.  This is not the sort of problem one likes to have - we are grateful, however, that we were able to reproduce and work around it! 

Former Member
0 Kudos

Have you tried it on Windows 7 or 8? Do you sell your app and one of your customers is choosing to run it on Vista or is it your company running internally on Vista?

Vista was a disaster that should be avoided and forgotten about as quickly as possible.

Former Member
0 Kudos

Our application is indeed commercial.  This particular customer just happens to be running an older version originally installed when Vista was current.

The majority of our customers run our application on Windows 7, 8, and some still on XP.  This problem does not occur on any of these Windows versions. 

We reproduced the problem ourselves because we still have a Vista test environment. 

Former Member
0 Kudos

...as should 8...

arnd_schmidt
Active Contributor
0 Kudos

Do you have any logic that sets the response window's X/Y-Position?

Eventually your window is displayed outside the screen area.

Former Member
0 Kudos

Thanks for your reply.  We do logic to set window's X/Y position, and we have had issues with windows positioned outside the screen area in the past.  We are confident this is not the case here because the <alt>+<space bar> keyboard action pops up a window control menu rooted at the top left corner of the invisible window, and this control menu is visible. 

We have found 2 of our response windows that have this problem on Vista, all the others are fine.  We plan to remove elements from the window one at a time to see if we can bring the window back.  We have a suspicion, and will report back.