Wednesday, December 21, 2005

More Integrated Updates for VFE

I just posted another set of integrated updates for VFE. There are a couple of things to note here.

1st, the cUtils class library was inadvertently included in the last set of integrated updates. A change to cGlobalHook that was not ready for primetime snuck in with that set. An updated version of cUtils that is ready for primetime is included in this set.

The work we've been doing on the Global Hook class has been in the enabled_assign_hook. Basically, what we've done with it is dumbed it down. It used to have a lot of code in it to deal with specific control classes and that code has now been moved to those specific classes. Please let us know on the forums if you notice any negative behavior with how controls are enabled or disabled in your applications. This should also correct bug #225D3CDB44CD41A4 which was the problem introduced by the inadvertent update we posted on 12/16/2005.

Included in this set of upgrades is also the fix for bug # 9FC33BA57BCD4FB4. The fix for this bug is in the vfewiz60 class library located in the wizards\libs\ directory beneath VFE. This is the first time we've put out integrated updates that change the wizard class libraries so be careful if you've made changes to any of these.

Toni also made a couple of enhancements that one of our consulting clients needed. She'll post more on these some time soon. In the meantime, I believe all of the the changes are in cBizObj and cCursor if you want to poke around yourself and have a look.

Blogger Spam

Ok, so this is getting a little out of hand now. Yesterday, I posted a blog entry about the GLGDW conference in April of 2006. Harmless topic, right? Wrong! Sometime yesterday afternoon a guy named "Jimmy" posted a nonsense comment to my blog entry. His comment included a URL that I followed and found to be a casino site. What is the cyber world coming to?

Thank you Jeff for noticing the comment so that we could delete it before too many people found it.

Tuesday, December 20, 2005

GLGDW is back in 2006!

Wow, I am so excited that Whil has decided to put on yet one more FoxPro conference. He is taking a slightly different approach to sessions and I think that this is exactly the sort of in depth conference that many developers could use about now.

The bummer is that we (Mike & Toni) will not be able to attend this great conference because we will be on vacation. We are going on vacation with Mike's sister and her family so it is sort if difficult to change our plans at this point. However we will stay tuned to the RSS feeds while we sun ourselves on the beach.

Friday, December 16, 2005

More Integrated Updates Released for VFE

Last night just before I hit the sack we put out a handful of updates to VFE. These updates are only available through VFE's Integrated Updates feature.

Here's a list of the bugs that were fixed since the last time integrated updates were released:

CEDFA65F5FDD4D84 cCursor Property lRepairWithSDT missing
B3E6DBDA498D459E ComboBox Quick Fill feature broke after VFE 2005 applied.
4406153DFC184E8E cTreeView SelectNextNode nit
FE75760809EF459E cSession Init nit
2A8DDF4217F94881 cPresentObjForm.Hide nits
3E36201022F54283 cBizObj Delete_Perform problem
FB7FE8B56AA248B9 Tools/Filter is broken

Most of the changes addressed some minor bugs that had been reported. I've got several other changes that I'm still beating up on in-house a little bit before posting, so stay tuned.

Friday, December 09, 2005

Visual FoxPro is a mover and a shaker

TIOBE Software - The Coding Standards Company

Somebody just posted a link to this article on the Wiki and I thought it'd be interesting to check it out.

The methods they use are a bit suspect, but it's still interesting nonetheless. Two things really stood out. First VFP made the most significant gains in popularity of all programming languages - moving from #51 to #20. That rocks!

The other thing that really stood out was the top 6. Java was is number one. C and C++ are 2 & 3. Combined that would make C number 1.

I was nice to see PHP at number 4. I knew it was popular, but not that popular. I have been leaning heavily towards getting into PHP when I consider developing skills in another language. There are a lot of things I like about it verses .NET and according to these rankings, it's more than twice as popular as VB.NET and C# combined.

VB at number 5 is no surprise. Perl at number 6 is. Again, I knew it was popular, but not that popular.

Anyway, this is good news for VFP. This and the FoxPro Not An Endangered Species article give VFP some long overdue respect and recognition.

Tuesday, December 06, 2005

Menu Performance

Just recently I was debugging a security issue in an application menu when I came across something very interesting. When you click on a menu pad the SKIP FOR condition is evaluated on every menu item in the menu. Wow! This can be a pretty big performance hit if you have a bunch of complex SKIP FORs. It just so happens that a user reported a menu delay on a pretty slow machine that very same day.

VFE menu bars have an Allow method that checks to see if a menu item should be available. There are many things that could disable a menu and security level is one of them. The Allow method becomes the Skip For condition on the menu bar. The checking for security level was the thing that was really hurting menu performance. This code was going out to a table to retrieve the access level. The actual method code was efficient, just not running so many times. In addition, the menu’s security level is read and written to a property when the menu bar is instantiated. Therefore, it does need to be looked up each time unless the user’s access level has changed.

I was able to fix the performance problem with a very simple change to the base menu classes. This example applies directly to a Visual FoxExpress menu but the code can easily apply to any Visual FoxPro menu.

Here is what I did:

  1. I added a property to my menu class called lRefreshSecurityLevelOnAllow.
  2. In the Allow method, the code that tries to find the security level is wrapped in an IF lRefreshSecurityLevelOnAllow.

If I want the security level to be retrieved, I can simply set the menu property to .T. and the next time the code runs, the security level will be looked up in the table.

In the VFE menu class, this property is .F. by default so that all menus get the best performance. If you have code in your application that allows the user’s security level to change while the menu is active, you can set the property to .T. in order to refresh the menu and then turn it back to .F.