Sunday, March 09, 2008
Visual FoxPro 9.0 SP2 or not... Post 4

Here are 3 more issues evaluated. We are still at low to medium impact for upgrading to SP2. Not nearly as bad as all the hype would lead you to believe.

There are some annoyances, no doubt, but I would like to get through the hype to find out what the real impact is. And I would still encourage anyone reading this, who has not installed SP2 yet, to download Rick Schummer's white paper and get SP2 installed and test it against your apps. And most importantly report any issues you find to Microsoft Feedback and/or the VFP9 SP2 Bug List page.

Issue: Right click on controls for code doesn't focus on correct control
Submitted By: Gary Parsons
New to SP2: Yes
Impact for SP2: Low
Feedback ID: 328226
Solution Available: No
Workaround Available: Yes
Bug Location: VFP9 Core

Here are the steps to reproduce from the Microsoft Feedback page:

1. Create form in Form Designer. Add some controls.
2. Right click on a object in a form... select "code" from the shortcut menu.
3. Close code window.
4. Right click on a different object... select "code" from the shortcut menu.
5. Code window opens with the previous object selected.

You can also reproduce the bug by selecting “View” -> “Code” from the system menu. It always shows the code from the previously viewed object. No matter what object is selected on the form. This is defiantly new to SP2. This behavior was not in previous versions of FoxPro. The workaround is to either double click on the control or use the “View Code” button in the “Form Designer” toolbar.

Should this stop you from upgrading to SP2? No. This may be annoying to developers who are used to using the right-click menu. But double click is just as easy. I would like to see this fixed myself, but since it is a designer only issues and should not affect your distributed apps I believe it has low impact on upgrading to SP2. If this is annoying to you, I recommend you click on the Feedback ID link and let Microsoft know about it.


 

Issue: Overlapped containers and visibility
Submitted By: Alexander Lagler
New to SP2: No
Impact for SP2: None
Feedback ID: N/A
Solution Available: No
Workaround Available: Yes
Bug Location: VFP9 Core

This is one of 2 issues reported by Alexander Lagler and added to the Visual FoxPro Wiki VFP 9 SP2 Bug List by Steven Black. As the description states; this issue is not new to SP2. It has even been around long before VFP9.

A test form is available for download. To test, run the form and click on the Listbox to see that it is active. Now click on the “Switch Container with Listboxes at same position” button. This changes the visibility of the 2 containers so now only the 2nd container is visible. When you click on this listbox, nothing happens.

The workaround can be simulated by choosing the “Set listbox’s visible property…” radio button. As the prompt states, it sets the Visible property of the Listbox when changing the Visible property of it’s container. It now works as expected.

Should this prevent you from upgrading to SP2? No. This is not a new issue. I did notice that this has no Feedback ID. I have not been able to locate it on Microsoft’s website. If someone knows if this has been reported, please send me a link to the Feedback ID.

 

Issue: Selecting from dirty VFP cursors (or tables)
Submitted By: Alexander Lagler
New to SP2: No
Impact for SP2: None
Feedback ID: N/A
Solution Available: No
Workaround Available: Yes, but your aren't gonna like it.
Bug Location: VFP9 Core

This is the 2nd issue reported by Alexander. It involves selecting data from a dirty buffered cursor in a large loop. The description hints that this is a new issue, but it is actually reproducible in VFP9 RTM and VFP9 SP1. It is NOT new to SP2. The repro code is in the same download as the previous bug.

The ability to SELECT from buffered data is new for VFP9. The issue can occur when you have several buffered records that are either inserted or deleted and then try to SELECT from that data. I have not been able to reproduce the issue with just UPDATEd buffered data. Only if INSERTs and DELETEs are included. The issue occurs whether you use the WITH BUFFERING = .T. clause or if you issue a SET SQLBUFFERING ON before issuing the SELECT.

It seems to happen randomly and can affect machines differently. Sometimes you get a C5 error and other times it just locks up VFP and spikes your CPU usage. I cannot find anything in the environment that could be use to determine that the error is about to occur. It appears that INSERTed or DELETEd data somehow gets a rogue pointer and sends VFP off into never-never land.

The workaround, is...well...don't SELECT from buffered data with known INSERTs and DELETEs. But if you haven't seen this issue yet, then you are probably OK, because the feature AND the bug were introduced in VFP9.

Should this stop you from upgrading to SP2? No. This is not new to SP2. This should not even stop you from upgrading from an earlier version of VFP because this feature is only available in VFP 9, so you are not missing anything. I cannot find this issue on the MS Feedback site either. If someone has the ID, please let me know or post it on the VFP9 SP2 Bug List page. If I don’t get a response back I will add this to the Microsoft Feedback page. This is a great feature; it would be nice to see Microsoft get it working properly.

 

What's Next:

I am getting a lot of request/questions about the reporting bugs. I may jump ahead to those and cover them in my next entry. The data group bug probably has the biggest impact for most people. My time will be limited over the next couple of days, but I will post what I can in the next day or two.

 


Monday, March 10, 2008 12:21:17 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0]  

Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: )  

Enter the code shown (prevents robots):