Foxpert Software Development & Consulting




What's the width of a combo list

If you have a combobox for which you don't specify a value for the ColumnWidths property, Visual FoxPro has to figure out itself how wide the dropdown list should be. Basically, Visual FoxPro makes this list just wide enough to fully display its values. However, Visual FoxPro only parses part of the list to determine the actual width of each line. The following code sample demonstrates this behaviour:

Public goForm, gaData[121]
goForm = CreateObject("Form")
For lnRow=1 to 120
  gaData[lnRow] = "_"+Transform(m.lnrow)
gaData[121] = "AAAAAAAAAAAAAAA*"
* first combo
goForm.c1.RowSource = "gaData"
goForm.c1.RowSourceType = 5
goForm.c1.ListIndex = 1
goForm.c1.Visible = .T.
* second combo
goForm.c2.RowSource = "gaData"
goForm.c2.RowSourceType = 5
goForm.c2.ListIndex = 100
goForm.c2.Top = 50
goForm.c2.Visible = .T.

Both comboboxes are set up with identical row sources. The only difference between the two is the currently selected item. The first combo displays the first item, the second one an item that is close to the end. If you now open both comboboxes, you will notice that the first one is narrower and won't display the last item at its full length.

VFP uses the current element and then reads a varying number of lines. In the sample above it's always 68 on my computer. That is, with a ListIndex of 53, the combobox behaves like the first one, with a ListIndex of 54 like the second one. In other cases I found the number lines to be much more like 10 putting the long line just outside the visible area of the seven default lines.


Translating Oracle's NVL2 function to Microsoft SQL Server

On Technet Microsoft states that the proper translation for Oracle's NVL2 function:

NVL2 (Salary, Salary*2, 0)

would be


WHEN null THEN 0



They got the Oracle part right, but miserable failed on the syntax of their own server. The correct way to use CASE with NULL values is





In Microsoft SQL Server you use IS NULL and IS NOT NULL to check for NULL. The original expression would always return the value from the ELSE part since the condition SALARY=null never becomes true.


Using FileMon

FileMon is a great utility if you need to debug performance problems in a Visual FoxPro application. After launching FileMon.EXE as an administrator change the filter to "VFP9.EXE" or the name of your application. When you now run your application, you can see all disk activities in your application.

One major pattern to watch out is a long list of read accesses on a single DBF file. These are usually table scan that are the result of un-optimized queries or frequent aggregations such as calculating sums or counts. When you test on a local machine you rarely notice these operations as a delay since your hard disk is fast enough to read dozens of MB in just one second. On a shared network, though, bandwidth is really criticial.

FileMon is pretty good at telling you what went wrong. However, it doesn't help you to relate this with the actual line numbers in your code. To achieve this I use markers in my Visual FoxPro application. A marker looks like this:


That is, I check for the existence of a not existing file. In FileMon this line produces output similar to the following:

11:14:08.182	vfp9.exe:2776	FASTIO_QUERY_OPEN
FILE NOT FOUND	Attributes: Error	

Now I can search for my markers in FileMon. I can be confident that all activities between two markers have been caused by the code between the two markers. By adding and moving markers I can quickly identify the lines that cause most traffic in an application.

Previous KnowlBits


February 2011 (2)

December 2010 (1)

October 2009 (2)

September 2009 (1)

August 2009 (4)

July 2009 (2)

June 2009 (2)

May 2009 (1)

April 2009 (1)

March 2009 (1)

August 2008 (1)

July 2008 (2)

May 2008 (1)

April 2008 (2)

January 2008 (2)

December 2007 (2)

November 2007 (2)

October 2007 (1)

September 2007 (1)

August 2007 (5)

July 2007 (4)

May 2007 (6)

March 2007 (3)

February 2007 (7)

January 2007 (6)

November 2006 (1)

October 2006 (3)

September 2006 (10)

June 2006 (2)

May 2006 (6)

April 2006 (1)

Impressum Kontakt Contact