Friday, July 14, 2006

I am a non-believer, let me tell ya.

Yes, I don't know when, but I became one at some point.

Not related to religion (or the lack of one) though and not a genetics issue either I think; the way I was raised, my mom and dad gave me the best education a son could have, I was given everything that's needed to be a double Nobel prizewinner in Physics and Peace just to give you an example.

Who knows, maybe the software world I am in made me the way I am these days.

If you've read my latest posts, you know I've been trying to use the RSS COM platform in IE 7 to create an RSS reader in Visual Foxpro, but haven't been succesful because, among other issues, it is not possible to bind RSS events from VFP.

Calvin Hsia found a solution, but his example is for cases that EVENTHANDLER can already address fine. He left as an exercise for the reader to figure out how to bind events for other COM platforms that don't quite work with EVENTHANDLER, indicating that following his example shouldn't be hard to figure it out.
Calvin, please believe me, IT IS.

OK, it's not that bad if you are good at C++, Assembly, x86 machine code and VFP.
But I'm not planning to learn 3 of those 4 languages at least in my next 7 lives.

Craig Boyd thanked Calvin because based on his example he found a solution to make RSS COM platform work with VFP. But Craig never posted his solution, although Calvin ceded him the honor to do so.

See? This is the kind of attitude that made me a non-believer. <g>

(read the thread at http://blogs.msdn.com/calvin_hsia/archive/2006/06/14/631604.aspx#634605)

A while back Andrew MacNeill suggested me to post the issues at the IE7 beta feedback MS web site, which I did with the same hope one buys a ticket for the big jackpot of the state lottery.

For the reasons exposed, I was in shock when I've got a response from the IE7 team that I'd like to share below.

Here's an excerpt from the email I received from the MS Connect Team,

There are 4 issues: 

1. unable to bind to RSS events: We have repro'ed it and are investigating the cause.

2. Download/update/refresh issue: We are unable to repro the hang after 4 downloads. Would it be possible to provide download logs created with http://fiddlertool.com ? It will create a snapshot of http traffic and will hopefully help us understand the issue better.

3. The feed view doesn't update when the feed is refreshed in the background. This is by design since there are cases where users would "loose" their read/unread state and the scroll position on the page if the page would automatically refresh.

4. Unable to delete feeds: This issue should be fixed in IE7 Beta 3. In previous releases an application could hold on to the Feed COM object and thereby preventing another application from deleting the feed. In Beta 3 we changed to an optimistic locking model allowing applications to delete feeds even if another app has the feed open.

Not bad for a non-believer huh?
Cheers from yours truly,

JLC.
Certified Non Believer

Ah! one more thing, Craig Boyd, if you are planning to conquer the world with VFP, in addition to need loyal soldiers, you will have to feed them as well...<g>

 

*This is the file MS feedback requested in item 2 testingie7.zip (355.88 KB)
posted on 7/14/2006 2:10:19 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [2]
 Wednesday, June 07, 2006
Experiencing the bitter taste of an unfinished software.
posted on 6/7/2006 6:37:37 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0]
 Friday, May 12, 2006

I used to think that blogs were the most idiotic thing in the world. That was not so long ago.

Nowadays I'd rather read blogs that surf web sites. Yes, I am the real idiot.

Who would've thought then, that I would be having fun building a VFP RSS Reader.
I will be posting more as I make progress, but here are a few pictures.

You may want to know from what I've done so far it took me less lines of code with Visual foxpro than with our, ahem rich cousin,  .NET.

[Update: forgot to mention that Calvin Hsia has built one also, using a different approach though]

posted on 5/12/2006 11:59:52 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [5]
 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)  #    Comments [2]
 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)  #    Comments [0]
 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)  #    Comments [10]


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)  #    Comments [3]
 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)  #    Comments [0]
 Sunday, January 22, 2006

Yeah man, yeah!.

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