Rick Strahl's Weblog
Rick Strahl's FoxPro and Web Connection Weblog
White Papers | Products | Message Board | News |

More on Vista FoxPro rendering issues.


25 comments
February 12, 2007 •

I mentioned a while back that there’s a UI based bug in VFP 9.0 on Vista that occurs when you have Fixed dialog windows loaded as child windows inside of other windows which causes window drawing inconsistencies which look like this:

 



The issue is related to any window that has a fixed border and while it may render properly if you don’t move it manually or programmatically as soon as you move the window or programmatically resize it the rendering will show pixel breakup around the edges.

 

The problem can be traced to the BorderStyle property and if you change a form that has a problem to be set with a sizable border (BorderStyle=3) the problem goes away.

 

It turns out that you can use this trick to get around this in code as well by setting the original BorderStyle to 3  (no border) and then in the INIT of the form set it to your actual value:

 

*!*   FORM’s Init event handler

DOEVENTS

this.BorderStyle = 2

 

This solved the issue for most of my forms that had issues.

 

However, I still have a couple of other forms that are progress indicators – they show popup windows that dynamically resize other windows to display progress bars or animations etc. In this situation even the trick above didn’t work and required adding the BorderStyle in the Resize code. At the beginning of the code I’d change the borderstyle to 3 and then at the end of the code back to whatever the original value was with some DOEVENTS in the middle. This too works around this issue but it's annoying:

 

THISFORM.oAnimationDialog.ResizeForm()

DOEVENTS

 

THISFORM.BorderStyle = 3

THISFORM.oAnimationDialog.StartAnimation()

DOEVENTS

THISFORM.BorderStyle = 2

 

THISFORM.GoOnline()

 

 

Menu Popup Rendering Bugs

There’s another visual Bug with VFP and Vista. This one has to do with menu popups not properly showing highlights. Basically highlight selections aren’t always clearing out when moving of a menu option and so you end up with menu that looks like mulitple selections have been made.

 

 

This also seem to happen in combo/dropdownlist box dropdowns which is even more annoying. I haven’t found a workaround for this one.

 

 

I sure hope Microsoft is going to fix these issues in SP2. While these are not critical failures of VFP, they are pretty annoying cosmetic bugs that make applications look very unprofessional. All of these issues are releated to VFP's internal rendering of controls I suspect since no other Windows applications - even ancient ones - are exhibiting these kinds of rendering inconsistencies.

 

Anybody running SP2 now and checked whether these rendering issues are addressed? I haven’t installed given the many problems people have run into with the SP2 CTP.

 

Posted in:

Feedback for this Weblog Entry


Re: More on Vista FoxPro rendering issues.



Doug Hennig
February 13, 2007

Hey Rick.

I just tested these issues under the CTP of SP2 and there's good news and bad news. The good news is that the shortcut menu issue seems to be gone. The bad news is that the combobox and the fixed dialog form issues aren't. Interestingly, some comboboxes display this behavior and some don't; I haven't had time to figure out the difference between the ones that do and don't yet, but I will. Your workaround for fixed dialog forms didn't work at all for me; the only solution I have so far is to set BorderStyle to 3 and prevent the form from being resized by setting MinHeight and MaxHeight to Height and MinWidth and MaxWidth to Width.

I also see bizarre effects with fixed dialog form title bars. If you drag a form so part of it goes off-screen, then back on, the title bar is "smeared". Also, if you press the mouse button down but not up again while it's over the close box, a different, old-style, close box (the real one as far as the window is concerned) appears.

They definitely need to get this fixed!

Doug

Re: More on Vista FoxPro rendering issues.



Rick Strahl
February 13, 2007

I think the shortcut and dropdown list issues are probably closely related using the same drawing algorithm for the popups. It's possible that different video cards have different effects on the problem. I don't see it totally consistent but with a few forms it's repeatable every time.

The example above with the image resolved with the code I used - it took a while to get to that particular solution. It'd be interesting to know whether this same code works for you or whether the result is different. The code is in the Offline Message Reader in the latest Web Connection build if you want to check it out.

I see the smearing too - basically I can see that if I move the form around the screen rapidly. In most cases though the title bar and border just disappear. I was running a couple of the Web Connection fat client examples and the forms would render without a title bar (well it's there it just doesn't render - I can click on where the close box should be and that actually works ...

Yeah, I really do hopw they get this fixed but I bet this isn't going to be easy for them. The price they pay for not using Windows control rendering...

Re: More on Vista FoxPro rendering issues.



Doug Hennig
February 14, 2007

Hey Rick.

Here's a workaround for the fixed dialog issue: set Desktop to .T. Not only does this fix the problem, it also makes VFP forms respect Aero: transparent borders, rounded rather than square bottom, shadowed, and "glowing" border controls (eg. close box).

Doug

Re: More on Vista FoxPro rendering issues.



Mike Potjer
February 14, 2007

Hi Rick,

Thanks for posting your findings on this (and a thanks to Doug, too, for his response). These posts are great resources for those of us who haven't had the opportunity to test on Vista yet.

One question -- are the problems you are seeing limited to having the Aero features turned on, or does VFP just have a problem with Vista graphics in general?

Thanks, Mike

Re: More on Vista FoxPro rendering issues.



Rick Strahl
February 14, 2007

Hi Doug, that doesn't really solve the problem because setting Desktop to .T. effectively makes the form a top level form that isn't modal. Top level forms already render properly. The issue only shows in MDI child forms which I mainly use because they are REQUIRED for modal dialogs. If you make a modal dialog a Desktop=.T. form it's no longer modal. I just played around with this a bit too - the behavior with Desktop=.t. is really funky anyway - focus doesn't work quite right. If you click something on the background then back to the 'modal' window it doesn't receive focus until you click on the title bar.

But it sure would be nice if child windows were able to look like this wouldn't it? I wonder if it's possible to rig up a mechanism to make non-modal windows behave like modal ones somehow, now that we have some control over Windows messages...

Mike, no these issues only occur with Aero on, but that's not much of a consolation since most people will run with Aero on or they wouldn't be running Vista I bet ...

Re: More on Vista FoxPro rendering issues.



Doug Hennig
February 16, 2007

Hi Rick.

I'm not seeing that with Desktop. I created a modal form, set Desktop to .T. (not ShowWindow to 2, which would definitely make it modeless), then called it from a modeless form. The modal form is definitely modal -- clicking on the calling form gives me the "ding, you dummy" sound and focus stays on the modal form (also, code immediately following the call doesn't fire until the modal form is closed). Switching to another application, then clicking on a textbox in the modal form restores focus to that form.

Doug

Re: More on Vista FoxPro rendering issues.



Josko Martinac
February 22, 2007

I have just installed VFP February CTP SP2, and unfortunately, none of the problems mentioned here are fixed.

Before Doug's solution, I tried to fix "FixedDialog" issue by making BorderStyle to 3 (sizable), and then set MaxHeight, MaxWidth, MinHeight, MinWidth to current Width and Height values.

Doug's solution is excelent, it is (for me) just a little bit annoying that forms are losing MDI child attributes, as Rick stated, but who cares when VFP form looks fantastic in Aero.

Well done, Doug.

Re: More on Vista FoxPro rendering issues.



Rick Strahl
February 22, 2007

Yeah, I'm going through Help Builder as we speak and re-designing some of my modal forms so they work properly with Desktop=.T. I suspect this particular issue of FoxPro MDI window rendering won't get fixed - although hopefully at least the blurring will.

To make the modal forms behave better I now use logic to pull the desktop modal form into the main form's view port with code like this (which centers):

FUNCTION CenterFormInParent(loParent, loWindow, llAddToolbarHeight)

loWindow.Left = loParent.Left + (loParent.Width/2) - (loWindow.Width/2) loWindow.Top = loParent.Top + (loParent.Height/2) - (loWindow.Height/2)

IF llAddToolbarHeight *** Fudge value for ActiveX menu loWindow.Top = loWindow.Top + 55 ENDIF

ENDFUNC

It works reasonably well. The only issue I have left is that some of my MDI windows are 'worker' windows that can be minimized. Previously they minimized into the VFP SDI window - now they minimize on the desktop and can get overlapped by other windows, but I suppose I can live with that.

Re: More on Vista FoxPro rendering issues.



Dominic Webb
February 23, 2007

I have found one form where the combo box problem (smearing the selected items) is inconsistent - on the problem combo I have some code in the Refresh Event. Removing the code fixes the problem.

In another form, I have a couple of combos, and nothing will fix them - in fact any combo box I add to the form with whatever settings exhibits the problem. I have compared the problem form with other similar forms and as yet can see no material differences.

I have also encountered a new visual problem. On one resizing screen, I have a number of labels in front of a themed shape (the shape just used to show a border). When I resize the form the labels' fonts go sort of bold, with the anti-aliasing broken. Other controls on shapes that resize do not exhibit the problem. If I put a label half way across the background screen and the sizing shape, then the label is half corrupted.

All of these problems are with VFP 8.

Re: More on Vista FoxPro rendering issues.



Josko Martinac
February 23, 2007

There is small problem with "Desktop=.T.".

Standard print preview window is below all other VFP forms.

Of course it can be easily solved using preview in predefined window, or using report listener, but sometimes I like "quick and dirty" solution: "REPORT FORM xxx TO PRINTER PROMPT PREVIEW.

Re: More on Vista FoxPro rendering issues.



Rick Strahl
February 23, 2007

Domnic, the label problem has always been a problem and it's related to TrueType fonts when ClearType is enabled. This is a major UI bug that Microsoft has never fixed and probably won't. It happens all the way back to Windows 2000. You can turn off cleartype for the machine and the problem goes away but that's obviously not a clear solution for end users.

Josko, this is a general problem with desktop=.t. It forces the window into a desktop window which is completely disconnected from the VFP window that launched so the Window zOrder is effectively hosed. I've found that I have to explicitly bring windows to the front including dialogs, which sucks big time.

Re: More on Vista FoxPro rendering issues.



Paul Warnick
March 05, 2007

Hi Rick,

We have the same issue regarding the combobox highlighting. Some cbo's work and others don't. So far I have tracked the problem down to the enabling of the combobox. If I issue a ThisForm.cboTest.Enabled = .T. in the init of the form (or in a checkbox click method) the combobox blurs the when it highlights. If I remove the ThisForm.cboTest.Enabled = .T., it works fine. Comboboxes that never have the enabled property touched work fine. This solution is ok on very simple forms but we have data selection that relies on user interaction and by default some cbo's must be disabled initially. Hopefully this gets addressed in SP2.

Re: More on Vista FoxPro rendering issues.



Ed. Stoessel
March 14, 2007

Hi, I also played around with this behavour (title bar does not render proprely). The most simple thing, was to add in activate methode of the form: This.TitleBar = 0 (even it was '1'), then This.TitleBar = 1. It seems to me, that this problem is solved. Ed

Re: More on Vista FoxPro rendering issues.



Brooks Adair
March 20, 2007

This information pointed me in the right direction for my Vista problems. I am using VFP 6.0 SP5 and my solution varied slightly so I will post my findings here to help anyone else still in an older version.

I found that with VFP 6.0 that if you touch the BorderStyle property at all the title bar will be come corrupt under Vista. In testing I ran a screen that was a direct subclass of the base VFP form and put THISFORM.BorderStyle = 3 in Load() and got the corruption. (Even though the default is 3). Also, if I set the BorderStyle to 2 then back to 3 through the designer I still have the problem. I had to right click on the property then click on reset to default. Then comment out any code in my base classes that touched BorderStyle. That did the trick for me. (No solution on the drop down issues yet).

BTW I don't think child MDI windows ever have the full Areo look, not even with other dev tools. I found some other apps that have child windows with no transparent title bar, and I don't think they were VFP apps.

Re: More on Vista FoxPro rendering issues.



Tracy Pearson
April 02, 2007

For the BorderStyle changed issue, If you reactivate the form, it will clear up the problem. I add the NOSHOW here to prevent the form from appearing in the INIT where I've placed this line of code.

ACTIVATE FORM (THIS.NAME) IN SCREEN NOSHOW

Re: More on Vista FoxPro rendering issues.



Rex Toomey
April 11, 2007

Tracey, should the correct syntax of your fix be

ACTIVATE WINDOW (THIS.NAME) IN SCREEN NOSHOW

Re: More on Vista FoxPro rendering issues.



Tracy Pearson
April 12, 2007

Yes, it should be Window. One of these days I know I'm going to learn to Copy/Paste code.

Thanks for correcting me.

Re: More on Vista FoxPro rendering issues.



Rex Toomey
April 13, 2007

No problems. You may be interested to know that I tested this out on my app running on Vista and it works a treat. I am not sure why only 10 out of say 130 forms were affected with the Vista rendering issue. I am wondering if I should put it in the INIT method of my base class - what do you think?

Re: More on Vista FoxPro rendering issues.



Tracy Pearson
April 13, 2007

I put it in the base form INIT method for our applications. Brooks Adair explained the problem above. It doesn't hurt anything.

This will quickly show the problem, and workaround. oFrm = CreateObject("Form") oFrm.Show() *-- Drag the form off the screen and back on, no problem oFrm.BorderStyle = 2 *-- Drag the form off the screen and back on, issues with the border ACTIVATE WINDOW (oFrm.NAME) IN SCREEN *-- Drag the form off the screen and back on, no problem

This piece of code, run in the development environment shows we still need it fixed in SP 2 MODIFY FORM test3 NOWAIT ASELOBJ(aform,1) aform(1).BorderStyle = 2 MOVE WINDOW "Form Designer -" TO 1,-100 =INKEY(.01) MOVE WINDOW "Form Designer -" TO 1,0 RELEASE aform

I did post the problem to Microsoft, with reproducible code here: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=265335

and another Vista related issue here: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=268681

Does voting for these issues help?

Re: More on Vista FoxPro rendering issues.



Rex Toomey
April 13, 2007

Hi Tracy, I am not sure if voting helps, but I certainly added my vote to your niffty workaround. As the old saying goes "Its the sqeaky wheel that gets the oil".

Re: More on Vista FoxPro rendering issues.



Brooks Adair
May 01, 2007

Calvin Hsia posted a fix for the combo box issue on his web log:

http://blogs.msdn.com/calvin_hsia/archive/2007/04/26/foxpro-menu-items-combo-boxes-not-refreshing-selected-item-under-aero-in-vista.aspx

Solution is simple, just put this code in your startup program: DECLARE integer GdiSetBatchLimit IN WIN32API integer GdiSetBatchLimit(1)

It works on VFP7 and up.

Re: More on Vista FoxPro rendering issues.



Ray
August 16, 2007

I noticed the same rendering issues with combo boxes in an app I was creating. It had been started using XP then I transferred to a Vista PC. Odd thing is that any combo boxes I added after the transfer to Vista worked ok. So I went back to the old forms and deleted then recreated the combo boxes and all render correctly.

Obviously this is not a solution for any applications that are already in service.

Re: More on Vista FoxPro rendering issues.



Clyde Butler
August 17, 2007

I have seen some of these issues as well, and found that my company is not as concerned about our apps running under Aero as they seem to run fine with the Windows Vista Basic Theme or to set the Desktop Icon Property on the Compatibility tab to "Disable desktop composition.".

My company is more concerned with basic compatibility and usability by our clients as they purchase Vista Computers. However, company management and I as well do not like the fact that the client will loose the Aero experience for the entire desktop and all apps running if they use either of these options.

Question: Is there a way to have our FoxPro 8 apps to run in the Vista Basic Theme or with the “Disable desktop composition.” and it only apply to our FoxPro app that is running and not the rest of the Windows Desktop and other apps that are running?

If all of you and the FoxPro community every figure out how to fix all the issue then we will re-evaluate the use of the Aero.

Thanks in advance for you help.

Re: More on Vista FoxPro rendering issues.



Kevin O'Shea
December 27, 2007

I found an issue with the code when placed on the init: ACTIVATE WINDOW (THIS.NAME) IN SCREEN NOSHOW In our application the user can bring up a number of forms in sequence and sometimes the same form can be brought up multiple times. The forms are all modal. When this code fires on the init, it pulls like-named forms behind the current form and out of the expected sequence that the forms were opened in. I have not found a work-around yet.

Re: More on Vista FoxPro rendering issues.



Siva
February 04, 2008

Hello Rick,

I'm using vista 64bit machine, i tried to solve the problem the way which you mentioned above...but whenever i'll give the code

borderstyle=2 && Fixed Dialog i need

i am facing the problem, that title bar of the form showing the background screen image.

I'm using with Visual Foxpro 7.0, will it work with VFP 9.0??

Thanks, Siva

 
© Rick Strahl, West Wind Technologies, 2003 - 2024