locked
cannot find object RRS feed

  • Question

  • In my development I have a small program (setlib.prg) that sets a lib using the same script as in my application startup:

    set classlib TO t:\common90\jvlib.vcx ADDITIVE
    oLib  = CREATEOBJECT("LIB")

    This lib contains a routine that is used in multiple tables to set a default value in a field validation:

    Default value: oLib.incredid("iidkey")

    If I modify the table and then try to save I get an error: Object OLIB is not found.

    If I run the program above as a program (RUN setlib.prg):

    set classlib TO t:\common90\jvlib.vcx ADDITIVE
    oLib  = CREATEOBJECT("LIB")

    ... I still get the error, But, if I run each of the lines separately in the Command window I do not get the error. I have the path set to the folder where the class file is located, so wouldn't you think vfp could find the lib?  I recently upgraded to a new PC with Win10... Is that the issue?  Same problem on two PC's with Win10.  Previous development environments did not have this problem with Win8 or older.

    This is kind of a "pain" to have to run these two lines of code every time I open the project.  Any ideas on what may be the cause... or what am I missing?


    John D. Vandervort

    Monday, March 14, 2016 4:35 PM

Answers

  • Well, I think depending on an object being instanciated for a table to work is a bad concept.

    But what doesn't really work? Have you really ported your VFP installation correctly on the new machine? It seems to me you lost some startup code instanciating the oLib object before you even first use the dbf. Did you forget creating/mapping a T: drive letter and copy over your lib? What about your old foxuser.dbf? _Startup?

    Besides that, in this case use NewObject:

    Public oLib
    oLib = NewObject("lib","t:\common90\jvlib.vcx")

    Bye, Olaf.


    Olaf Doschke - TMN Systemberatung GmbH

    http://www.tmn-systemberatung.de


    • Edited by Olaf Doschke Monday, March 14, 2016 6:57 PM
    • Marked as answer by JohnCompass Monday, March 14, 2016 8:35 PM
    Monday, March 14, 2016 6:55 PM

All replies

  • Well, I think depending on an object being instanciated for a table to work is a bad concept.

    But what doesn't really work? Have you really ported your VFP installation correctly on the new machine? It seems to me you lost some startup code instanciating the oLib object before you even first use the dbf. Did you forget creating/mapping a T: drive letter and copy over your lib? What about your old foxuser.dbf? _Startup?

    Besides that, in this case use NewObject:

    Public oLib
    oLib = NewObject("lib","t:\common90\jvlib.vcx")

    Bye, Olaf.


    Olaf Doschke - TMN Systemberatung GmbH

    http://www.tmn-systemberatung.de


    • Edited by Olaf Doschke Monday, March 14, 2016 6:57 PM
    • Marked as answer by JohnCompass Monday, March 14, 2016 8:35 PM
    Monday, March 14, 2016 6:55 PM
  • Thanks.  It was several years ago that I had to do that... forgot it was necessary, since my app that sets that up was working ok.


    John D. Vandervort

    Monday, March 14, 2016 8:37 PM
  • OK, it's still unclear what you forgot to do, but it's very typical of a move to a new system you forget to move some settings, configs, mappings, initialisations you once configured in the old system and forgot about, as they simply work.

    It's a reason to document such things, even the simplest ones.

    Bye, Olaf.


    Olaf Doschke - TMN Systemberatung GmbH

    http://www.tmn-systemberatung.de

    Tuesday, March 15, 2016 7:41 AM
  • I see one thing: The scope of the variable.

    If you simply run that prg oLib is released in the end. If you start an app having that in it's main.prg you hacve a quasi public variable, as you have a private variable never being released, as main.prg always remains in the call stack.

    If you do the single lines in the command window you also make oLib quasi public, as that's the only way making sense. If any code you execute in the command window would be turned to a single line prg being executed, any variable would be released right away, so that isn't done and ie oLib stays in scope, but not if you run that prg, then it's instanciated and released right away, unless you declare it PUBLIC.

    So perhaps take a look at the meaning of variable scopes and PUBLIC, LOCAL, PRIVATE, and (very special) REGIONAL/#REGION

    Bye, Olaf.


    Olaf Doschke - TMN Systemberatung GmbH

    http://www.tmn-systemberatung.de

    Tuesday, March 15, 2016 7:50 AM