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

Visual FoxPro and Vista RTM


Monday, November 20, 2006, 12:03:00 AM

A few days ago I installed Vista RTM on my main development laptop machine and it went well. I’ve been using Vista since Beta 2 exclusively and my last install comes of RC1. RTM is a big step up from RC1 both in performance and overall polish of the UI and so far I haven’t run into any issues.

 

There are however a few UI oddities with all of my Visual FoxPro applications. I’ve found that many forms that are child windows of other forms are not properly sizing or losing their borders inconsistently when running under Aero. In many of my applications like the Message Reader and Help Builder I frequently have non-interactive message windows that pop up to indicate progress information and messages. For some reason all of these windows are mis-sized and show with their borders corrupted.

 

Here’s an example:

 

 

This is a dynamically resized dialog. The form is brought up and then resized. I've played around with additional refreshes and DOEVENTS, but nothing helps.

 

It looks like this is a problem with Aero – turning off Aero renders this dialog properly. Unfortunately I can’t really test this out with another video driver since Aero won’t run with the VGA driver <s>. Maybe somebody running the message reader can check and see if they’re also seeing this behavior with Vista and Aero. Use a long date range for the download date range to see the dialog more than a second <s>.

 

Unfortunately it’s not isolated to windows that are resized. Occasionally I see this behavior on just plain child windows. Thankfully it’s only child windows that exhibit this behavior but it’s still annoying. I have no workaround for this at the moment, but being cosmetic it’s not exactly a show stopper.

 

.NET 3.0 Runtime Gotcha

The good news is that I’ve got all of my applications installing and running great on Vista otherwise. Help Builder required a few fixes for Vista specifically in relation to the .NET 3.0 runtime availability which screwed up the .NET version checks. Microsoft really screwed us with this bogus version numbering - .NET 3.0 is not really a new version of the .NET framework as it depends on the .NET 2.0 installation and there’s really no such thing as ‘running’ a .NET 3.0 application. I have a set of runtime checks in my application that detects the latest version installed and it failed with 3.0 but of course none of the runtime files can actually be found there so this was a problem. Here’s an updated .NET runtime version check:

 

************************************************************************

* wwUtils :: IsDotNet

****************************************

***  Function: Returns whether .Net is installed

***            Optionally returns the framework path and version

***            of the highest installed version.

************************************************************************

FUNCTION IsDotNet(lcFrameworkPath,lcVersion)

LOCAL loAPI as wwAPI, x

 

lcVersion = ""

lcFrameworkPath = ""

 

loAPI = CREATEOBJECT("wwAPI")

lcWinDir = loAPI.getSystemdir(.t.)

 

IF EMPTY(lcVersion)

   *** Assume .NET 2.0

   lcVersion = "v2.0.50727"

  

   lcWinDir = loAPI.GetSystemdir(.T.)

  

   *** Try to find the largest version number

   lcFrameworkPath = lcWinDir + "Microsoft.NET\Framework\"

   lnCount = ADIR(laNetDirs,lcFrameworkPath + "v?.*.*","D")

   FOR x = lnCount TO 1 STEP -1

      lcVersion = laNetDirs[x,1]

      lcTPath = ADDBS(lcFrameworkPath + lcVersion )

      IF FILE(lcTPath + "regasm.exe")

         lcFrameworkPath = lcTPath

         EXIT

      ENDIF

   ENDFOR

  

   RETURN .T.

ENDIF

 

*** Strip of the build number and replace with 0

lnAt = AT(".",lcVersion,3)

IF lnAt > 0

   lcVersion = SUBSTR(lcVersion,1,lnAt) + "0"

ENDIF

 

lcFrameworkPath = loAPI.Readregistrystring(HKEY_LOCAL_MACHINE,"Software\Microsoft\ASP.Net\"+lcVersion,"PATH")

IF ISNULL(lcFrameworkPath)

   lcFrameworkPath = ""

ELSE

   lcFrameworkPath = ADDBS(lcFrameworkPath)

ENDIF  

 

RETURN .T.

ENDFUNC

*  wwUtils :: IsDotNet

 

This code basically looks at the .NET paths and then reads backwards from the highest version until it finds RegAsm.exe which is one of the binaries that comes with .NET. .NET 3.0 doesn’t have this since it’s only a library version so it won’t be included in this check. IOW, this code only returns the ‘real’ runtime version <s>…

 

Program Files and User Account Control

Another more serious issue that will affect many applications is the default security environment and User Account Control. By default the Program Files Folder is off limits for writing files to local users. This means if you have applications that write in this directory things are going to work a little differently and maybe uh – unpredictably.

 

First the issue is that the default user by default has no write rights in the Program Files folder so if you install any applications there that require writing files – any files like configuration files or data files – that won’t work like it did under XP.

 

Now Vista does something here that will make MOST (but not all) applications run anyway even though the active user can’t write in this directory. Vista virtualizes the Program Files folder so when the application tries to write to disk it sticks the output user specific folder virtual folder in your user profile.

 

 

This will make your application work as long as it’s meant to be a single user application. Ah – but this will break your application if you need to have multiple users access the file either on the same machine with different user accounts or simultaneously via drive mapping.

 

If you need to share files between users either on the same machine or a different machine you’ll want to make sure that you install your data files in a separate location. This is nothing really new I suppose – Microsoft’s been harping on these guidelines for some time, but Vista enforces it.

 

Disable Admin Approval Mode

You can also get around for your own machine (but probably not for your customers <s>) by disabling Administer the ‘User Account Control: Run all Administrators in Admin Approval Mode’. With this option disabled are back to being Master of your Domain and get almost full control of your machine.

 

You can find this option with: Run gpEdit.msc. Then: Local Computer Policy | Computer Configuration | Security Settings | Local Policies | Security Options. The User Account Control options are at the end of the list and you can turn most of that crap off if you’re tired of the constant sleet of approval dialogs. But be aware that this will diminish some of Vista’s security if you’re the paranoid type and don’t take care of your machine <s>…

 

IIS 7

One of the big reasons for using Vista if you’re doing Web development is IIS 7. IIS 7 in the Ultimate and high end business SKUs for Vista provide a full version of IIS that has no limitations. You can create multiple Web sites and you can stress test at full throttle. There are no connection limits. The non-high end skus still have connection limitations but instead of being hard errors these will just queue effectively throttling IIS rather than throwing the annoying Too many connections that XP did. All versions of Vista include IIS although Home Basic and Starter don’t have any way to configure it. So we’ll have to wait and see how that works for development if at all. I have to set up a VPC to check that out.

 

IIS 7 has many improvements including a new pipeline that allows getting rid of ISAPI and replacing it with a much more streamlined pipeline that can create Web server extensions with either .NET code or Win32/C++ code. The programming of these interfaces is MUCH easier than ISAPI was providing an ASP.NET like architecture so it’s much easier to create complex code and take advantage of features. I’m a good ways into a rewritten handler for the Web Connection low level interface and it’s a pleasure updating to this code from the nasty ISAPI C++ code. But this is not real critical, since ISAPI still works just fine in IIS 7.

 

The biggest issue is that IIS 7 doesn’t install by default – you have to install from Windows Components. When you do make sure to enable IIS 6 Configuration compatibility which is required for just about any Web Application that has automatic installation. This includes Web Connection and anything related to Visual Studio’s Web projects. So make sure that these options are checked.

 

The installer by default also has many common modules disabled. For example, Windows Authentication, Basic Authentication, ISAPI, ASP.NET, ASP and many other common operations are all off by default. You should take a close look at the configuration settings.

 

Good news is that as far as Web Connection is concerned everything works without any issues. Installation works with the exception of the Visual Studio configuration (looking into that – but you can manually add the controls to the toolbox and configure the editor script mapping via the documentation).

 

I’ll have a more detailed post and a doc update soon with more detailed installation steps for IIS 7. But even without that Web Connection 5.15 should install without any fanfare on Vista.

 

Eventually I need to migrate the configuration routines to use the new WMI provider. Many configuration settings now are actually stored in the web.config file in the virtual root directory so the setting made there immediately become portable and application specific. This is a huge feature for any kind of Web application you need to move/update or install on many machines! The management console automatically writes changes into this file too so there’s nothing special that has to be done to do this.

 

 

Ok, that’s it for the moment. I’m glad to see that there’s relatively little impact to applications on the surface. I’m sure as time goes on we’ll find more issues we’ll need to deal with, but overall a big thumbs up from my end.

Posted in:

Feedback for this Weblog Entry


Re: Visual FoxPro and Vista RTM



Kevin Wright
Does the VFP9 SP2 Beta solve any of this?

Kevin

Re: Visual FoxPro and Vista RTM


Kevin I don't know. I haven't installed SP2 after seeing the many problems others have been having with it. The only thing that would be affected is the funky dialog behavior and as I mentioned at this point I'm not sure if this is a video driver problem or an AERO related issue.

Re: Visual FoxPro and Vista RTM



Kevin Wright
> I haven't installed SP2 after seeing the many problems others have been having with it.

I know the feeling :-) I keep intending to set up a VPC to try it on. Trouble is, I don't know how you can install Vista on VPC 2004 hosted on XP.

Kevin

Re: Visual FoxPro and Vista RTM


Running Vista on VPC has never really worked for me - it's been way to slow to be usable even on a fast machine with a second drive for the VHD partition. But maybe with the Release version this is better...

Re: Visual FoxPro and Vista RTM



Dominic Webb
So far I have only tested with VFP8 sp1, and I am seeing a number of problems with borders and window titles. Specifically, on forms without control boxes/icons, the title bar is not rendered. This behaviour is intermittent, and the title bar is present - you can move the form. Where there is a control box or icon, dragging the form off the screen and back results in visual corruptions of the title bar.

Re: Visual FoxPro and Vista RTM


Dominic this sounds similar to what I'm seeing. Are you running with Aero on? When I turn Aero off these problems go away. It seems it's only MDI windows that are problematic.

Re: Visual FoxPro and Vista RTM



Dominic Webb
Yes - switching the Appearance settings from Windows Aero to Windows Vista Basic corrected the issue.

Re: Visual FoxPro and Vista RTM


Regarding the form display issue, I've isolated the problem to the following:

Child Window (In Top Level Window)
Fixed Border (none, single, dialog)

If you have a window with these attributes and move the window around inside of the parent form you'll see this form corruption.

I've bugged this here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=248856

Re: Visual FoxPro and Vista RTM



Ed Herrera
I encountered the same error with the UI display issue using aero; something interesting, if I execute the application using the "run as administrator option"; then the display works!!!. interesting huh?

Re: Visual FoxPro and Vista RTM



Ed Herrera
Rick, i know it makes no sense at all. But on my test system. Running Vista Ultimate default installation; (UAC on, everything on) if i run my executable as (right click, run as administrator) it will display the title bar on the child non sizable windows.

It makes no sense at all, unless running it with this option turns off Aero for that app, or something to that effect.

Re: Visual FoxPro and Vista RTM


Hey Rick,

I've seen this behavior this week, and I 'fixed' the issue by setting the form's Borderstyle=3 (resizable).

After that, I set the MaxHeight, MinHeight, MaxWidth and MinWidth to the same values as the form Height and Width.

This 'fixes' the diappearing title bar and borders, but the user will see the resize cursor when hovering over a border.

Kevin

Re: Visual FoxPro and Vista RTM


Hi Kevin, yes as I mentioned in one of the comments below, the fixed size of the border seems to cause this re-drawing problem to occur. As soon as the border is marked as resizable the problem goes away. So your 'fix' works although that's a pain and kinda non-standard. Hopefully this will get fixed in SP2, but I haven't heard back on that bug report. In fact I've heard nothing from Microsoft on any sumitted VFP bugs <shrug>...


Re: Visual FoxPro and Vista RTM



Joe Majestic
Hi Rick,

Thanks for the heads up about Vista's new User Account Control (UAC) and how it may cause problems with VFP apps.

I distribute a VFP 9.0 application and started receiving numerous emails regarding issues running it under Vista. I configure InstallShield to no longer install this program under Program Files but to instead install it off of the users root drive. All the problems users were reporting were resolved. this is a very important tip so everyone reading this should take note.

Thanks again Rick.

Joe M.

Re: Visual FoxPro and Vista RTM



Joe Majestic
Rick,

I've found another issue related to Vista. When I try to build my VFP projects using InstallShield, I get a number of erros. I've found work-arounds for most of these errors but one error persists.

ISEXP : fatal error -6017: Internal build error

I think the InstallShield is having trouble registering two DynaZip DLL's that I include with my solution. This error does not occur when compiling the setup under Windows XP.

I've been searching the web for answers or to even find threads that suggest if others are experiencing the same issue with InstallShield, but so far I've found nothing.

I haven't found any help on Macrovision's site as well.

If you or anyone reading this knows what is happening, please post a reply.

Thanks
Joe

Re: Visual FoxPro and Vista RTM


The border problem is caused by the parentclass borderstyle being overwritten in the implementation.
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

Re: Visual FoxPro and Vista RTM


Thanks to this enlightening article, and the reply and tip by Joe Majestic (02/15/07 2:32) I think I have found the answer to a problem I posted on the Foxite forum.
http://www.foxite.com/forum/read.aspx?id=129129
Ive been battling with this problem for a month now.

Thanks guys!

Re: Visual FoxPro and Vista RTM



Daniel
Running a Vista VPC on VMC 2007 works. Just make sure to install the addons via File menu. Vista should run very smooth, and make sure that you have atleast 2 Gigs of Ram to use. Haven't had the courage to install SP2 myself as service packs never tend to fix the problems im having they just add to the madness. I'll wait for more developer comments.

As for running as admin, if you install anything on vista you have to install it AS an admin. Microsoft in all their wisdom decided that someone with admin rights and a full blown admin are 2 different things.

Re: Visual FoxPro and Vista RTM



Bob Archer
Rick,

I assume you say the solution/workaround for this on Calvin's blog. It appears it will be fixed in VFP9 SP2. Of course, that doesn't help for VFP7 apps. !!!

http://blogs.msdn.com/calvin_hsia/archive/2007/05/01/windows-vista-aero-borderstyle-paint-problem-as-non-administrator.aspx

BOb

Re: Visual FoxPro and Vista RTM


Rick - servus!,

So what's the best place to install files that might get changed to?

No question, in a Network-environment the data goes on to the server.

But how about files like INI-Files, Helpfiles (that every now and then get updatet via online-Update), .... files that are not data but get modified eventually or every now and then without being a new "Setup"?

I have seen the hidden C:\ProgramData. A folder underneath that one could be an option or should we take the common Documents - folder as bases.

Sure, I'll make this a choosable option in my Setup, but what to take as default?

Regards from Berlin

Frank

Re: Visual FoxPro and Vista RTM



DL
I got over 200 forms need to deal with and I have so far learn there is no better solution by changing BorderStyle = 3. So, I decide it is time to let machine do its work and people do his.

The default BorderStyle in our system is resizable(3) and in numeral occasion we use fix border (about two-third ). The following sample code go through each form (SCX), remove BorderStyle statement from properties of 'form' object and reinsert it into last line of form init procedure.

By the way right click the program and "Run As Administrator" which is different from someone is administraor also give me the proper border display, but I can't expect every users to do that.

I sure hope VISTA SP1 will fix this problem.

-----------Sample code
nForms = ADIR( aForms, '*.scx' )
STORE 0 TO i, j
SET DELETED ON
SELECT 0

FOR i = 1 TO nForms
USE ( aForms[i,1] )
* assume all single for no formset
LOCATE FOR LOWER(TRIM(baseclass)) = 'form'
IF FOUND() AND 'BorderStyle' $ properties
SCATTER FIELDS uniqueid, properties, methods MEMO MEMVAR
m.dbfname = DBF()
= processMethod()
= updateForm()
ENDIF
ENDFOR

CLOSE DATABASES ALL


CLOSE DATABASES ALL

PROCEDURE processMethod()
* m.properties
* m.methods

LOCAL s1, s2, s3, n1, n2, nborder

nborder = LEN( 'BorderStyle = 2 ' )

s1 = LEFT( m.properties, ATC('BorderStyle', m.properties)-1 )
s3 = SUBSTRC( m.properties, LEN( s1 ) + 1 )
s2 = SUBSTRC( s3, nborder + 1 )
s3 = LEFTC( s3, nborder )
m.properties = s1 + s2

n1 = ATC( 'Procedure init', m.methods )
IF n1 = 0
m.methods = m.methods ;
+ 'PROCEDURE init' + CHR(13)+CHR(10) ;
+ s3 ;
+ 'ENDPROC'
ELSE
s1 = LEFTC( m.methods, n1 - 1 )
s2 = SUBSTRC( m.methods, n1 )
n2 = ATC( 'ENDPROC', s2 )
** check if there is .BorderStyle already in code, but we can't be sure if it is comment or active code
IF ATC( 'BorderStyle', LEFT( s2, n2) )=0
m.methods = STUFF( m.methods, n1 + n2 - 1, 0, 'thisform.' + s3 )
ENDIF
ENDIF
RETURN
ENDPROC

PROCEDURE updateForm()
GATHER MEMO MEMVAR
RETURN
ENDPROC

Re: Visual FoxPro and Vista RTM



Andrew Hall
So does the InstallShield Express 5.0 that comes with VFP9 work with Vista, or does Vista require some other Macrovision product?

re: Visual FoxPro and Vista RTM



Gerard Buijze
I've installed the same Foxpro application under Vista Home Premium and under Vista Ultimate. Just clean setup, no settings changed and guess what?? Under Vista Home Premium the "highlighting every row" issue in the combobox occurs but under Vista Ultimate it does not. I checked the compability settings but they were the same too. So my guess is that somewhere else in Vista is causing this different behaviour, but what???

Any comments can be send to foxserv@xs4all.nl subject "Visual Foxpro & Vista"

 



© Rick Strahl, West Wind Technologies, 2003 - 2018