Thursday, March 16, 2006

I recently run into the problem of not getting the right order for records on a temporary table. This is how data looked when using and index created as follows:

INDEX ON UPPER(company_name)+UPPER(dept_name)+UPPER(EMPLOYEE_LASTNAME)+UPPER(EMPLOYEE_FIRSTNAME) TAG ciadeptemp

COMPANY_NAME,DEPT_NAME,LAST_NAME,FIRST_NAME
Company 1, null,j,c
Company 2, Sales,f,c
Company 1,Tech Support,g,c

What happened? Shouldn't I get all the 'Company 1' records before seeing 'Company 2'? Of course, but that is in case there were not null values in any of the fields that are part of the index key.

In my case, field "dept_name" accepted .null. values so the index key for that record evaluates to .NULL., therefore, appears at the top. This new index key solved it:

INDEX ON UPPER(company_name)+UPPER(IIF(ISNULL(dept_name),space(40),dept_name))+UPPER(EMPLOYEE_LASTNAME)+UPPER(EMPLOYEE_FIRSTNAME) TAG ciadeptemp

Never run into this before, so many years working with VFP but how much I've got to learn yet. Did anybody resolve this in a different way?

posted on 3/16/2006 1:01:10 PM (Eastern Daylight Time, UTC-04:00)  #   
 Friday, February 17, 2006

A colleague using VFP7 asked recently about removing those pesky printer references in reports. Of course, you have a way to manually remove them in VFP8 and VFP9 (report menu-printer environment and also for VFP9 report properties).

In case you still maintain projects in VFP7 and/or upgrade report files into projects using versions 8 or 9, trying to remove those printer references (if any) automatically won't hurt your project after all. The best known option for this is to put some code in your project hook class 'beforebuild' method.

Most Fox people know that they can associate a ProjectHook visual class with their projects using the Project Menu options available; Since I couldn't send to my colleague the visual class as a file  (it was an internet newsgroup), I thought of a way to do this programatically so here's another way to do it, probably useful in case you had your classes defined in a prg. The downside is that the ProjectHook reference does not persist when you close the project.

This code takes care of creating the class file and adding at least one file to the project in order to build it as an APP, needles to say these are things needed for this example only, in a real life scenario those 2 would be existing files.

#include foxpro.h
clear
IF FILE("foo.prg")
    DELETE FILE FOO.PRG
ENDIF

IF FILE("MyClasses.PRG")
    DELETE FILE MyClasses.PRG
ENDIF

IF FILE("MyProject.pjx")
    DELETE FILE MyProject.*
ENDIF


LOCAL lcMyProjectHookVar
TEXT TO lcMyProjectHookVar noshow
    **************************************************
    *-- Class: myphook (c:\noninteractive\annunciacurrent\phookexample.vcx)
    *-- ParentClass: projecthook
    *-- BaseClass: projecthook
    *-- Time Stamp: 02/17/06 03:49:02 PM
    *
    DEFINE CLASS myphook AS projecthook


        Height = 22
        Width = 23
        Name = "myphook"


        *-- Cleans Fields EXPR, TAG, TAG2 Contents On First Record Of Report File
        PROCEDURE cleanreportprinterreferences
            PRIVATE a
            WITH _vfp.ActiveProject.Files
                FOR a=1 TO .Count
            
                 IF UPPER(JUSTEXT(.Item(a).Name))="FRX"
                 USE .Item(a).Name EXCLUSIVE
                 REPLACE expr WITH "", tag WITH "",tag2 WITH ""
                 PACK
                 USE IN JUSTSTEM(.Item(a).Name)
                 ENDIF
            
                NEXT
            ENDWITH
        ENDPROC


        PROCEDURE BeforeBuild
            LPARAMETERS cOutputName, nBuildAction, lRebuildAll, lShowErrors, lBuildNewGuids
            WAIT WINDOW "Hello World from BEFOREBUILD" TIMEOUT 5
            THIS.CleanReportPrinterReferences()
        ENDPROC


    ENDDEFINE
    *
    *-- EndDefine: myphook
    **************************************************endtet
ENDTEXT
STRTOFILE(lcMyProjectHookVar ,"MyClasses.PRG",0)
STRTOFILE("* Main Program PlaceHolder","FOO.PRG",0)

SET PROCEDURE TO MyClasses.PRG

MODIFY PROJECT MyProject NOWAIT noshow
_VFP.ActiveProject.ProjectHook = NewObject('MyPHook')
IF VARTYPE(_VFP.ActiveProject.ProjectHook)=="O"
    ?DATETIME(),": ProjectHook Created Succesfully"
ELSE
    ?DATETIME(),": WARNING->ProjectHook NOT Created Succesfully"
ENDIF

IF FILE("FOO.PRG")
    _VFP.ActiveProject.Files.Add("FOO.PRG")
    ?DATETIME(),": FOO.PRG added to the project, BUILD about to run."
    IF _VFP.ActiveProject.Build(JUSTSTEM(_VFP.ActiveProject.Name), BUILDACTION_BUILDAPP )
            ?DATETIME(),": BUILD WAS SUCCESSFUL!"
    ELSE
            ?DATETIME(),": WARNING->BUILD WAS UNSUCCESSFUL"

    ENDIF
ELSE
    ?DATETIME(),": WARNING->Could not add a file to the project, BUILD not run."
ENDIF


_vfp.ActiveProject.Visible=.t.

posted on 2/17/2006 11:12:00 AM (Eastern Standard Time, UTC-05:00)  #   
 Tuesday, January 31, 2006

I remember, a while ago, two famous FoxPro gurus were fighting on what Visual FoxPro was going to be able to do running (if ever possible) on Longhorn and Avalon (now WPF).  One of them claimed that the impact of these new technologies was going to be of such magnitude that would leave VFP totally out of the game. The second guru, needles to say, denied this. It was a colorful discussion, both got carried on to a point guru #1 proposed to bet money to show how serious he was.

As guru #2, but for different reasons, I thought #1 was wrong.

These pictures speak by themselves. In case you didn't notice, it's FoxPro 2.6 DOS and VFP 9 running on Windows VISTA (formerly Longhorn) PDC 2005 build. In addition, I was able to run a FoxPro DOS program (built back in 1993) flawlessly without touching a single line of code.

But this means nothing compared to what can be seen in Ken Levy’s Channel9 video, (I recommend the whole video but, for what is worth, the fun starts at minute 21). 

Now, is it me or one of these 2 persons proved to be soooo... wrong? I am also wondering what they may think now...

posted on 1/31/2006 6:15:13 PM (Eastern Standard Time, UTC-05:00)  #   


A colleague on the UniversalThread  reported getting this error  when building his setup using InstallShield for Visual Foxpro

Resolving strings...
ISEXP : error -6264: A record in the Property table is using string ID 'ID_STRING1' for column 'Value' but this string is blank and the column is not nullable

I believe this problem is either a bug or corrupted ism file.

Although IS does not store data in SQL database, trying to apply similar concepts, you would agree with me that the program is trying to save a .null. value into a field who does not accept such values; since you can't modify that in IS Express for VFP, the only solution seems to be to fill that entry with some string value.

  1. Open your ism project
  2. Click on plus sign to open "Organize your setup” option branch
  3. Look for every single entry that requires a text entry and make sure there’s a string entered for each one, if not, enter some text, example being, “Publisher/Product URL” needs a string value, and so on.
  4. Rebuild your project, be happy again. If still did not work look into the rest of the project where a string entry is required and do your thing.

It is difficult, if not impossible, with this limited version of IS to determine the offending field by using the description given in the error message  'ID_STRING1'.

You could easily know this however. That is in the case you had the full version of IS Express:

  • Use the menu option "Project-Export String Table”  to create a text file with your project info. Do this at least once before you build the project the first time.
  • When you get an error, open this text file and look the value reported in the error message to which project option refers
  • Go back to your ise file and correct only the offending field.

This is how the txt file looks like:

posted on 1/31/2006 2:34:50 PM (Eastern Standard Time, UTC-05:00)  #   
 Monday, January 23, 2006
Technorati Profile

Trying to set it up...

posted on 1/23/2006 6:21:07 PM (Eastern Standard Time, UTC-05:00)  #   
 Sunday, January 22, 2006

Yeah man, yeah!.

posted on 1/22/2006 3:00:00 AM (Eastern Standard Time, UTC-05:00)  #