URUN call-in not working any more?!

Author: kevin.palm@labsolution.lu (palm.kevin)

Hi all,
I need to launch a Uniface form from an external C application (Both running on Windows 7).
In the Uniface documentation I found the information I needed to do such a 3GL operation: URUN.
I wrote a small C application to test this call (callin.c):

#include <h3gl.h>
void main (void)
{
 unifbeg(0);
 urun("PSCRIPT_PYT.frm", 0, 0, 0, 0);
 unifend(1);
}


To compile my application, I executed the following instructions:
cl  /c /I "C:\Uniface94\uniface\3gl\include" callin.c
link /OUT:"callin.exe" "/LIBPATH:C:\Uniface94\uniface\3gl\lib"  ucall.lib urtl.lib ulib.lib yrtl.lib callin.obj
 

 
The compilation and the linking worked both. Now when I execute the program callin.exe, I get the following error message:
The ordinal 574 could not be located in the dynamic link library ULIB.dll
I really don't understand this error:

  • URUN is NOT defined at ordinal 574 of ulib.dll, but at ordinal 41 of yrtl.dll ?!
  • At ordinal 574 in ULIB.dll is function "_uSql2Trx" ... ?!?

Can anybody provide some help on this topic?!

Best thanks beforehand,
Kevin Palm

Additional information concerning my system:

  • OS: Windows 7 (64 bit)
  • Uniface: 9.4.0.1 (32 bit)
  • C Compiler: Visual C++ (32 bit)

12 Comments

  1. Hi,

    Some time ago I tested the same kind of situation and I got it working. Unfortunately I don't remember very much about it and I never had to use it.
    I think I remember that it was very important to use a manifest file  "myappl.dll.manifest" (info from Compuware), otherwise it didn't work. Something like this:

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
    <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
    <dependency>
    <dependentAssembly>
    <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
    </dependency>
    </assembly>

    Regards RogerW.


    Author: rogerw (roger.wallin@abilita.fi)
  2. Hi Kevin,

    I was able to see the same problem.

    You might move the callin.exe to the common\bin directory. Then the right ulib.dll can be found.

    When you only start Uniface from your program, then you also can use windows function CreateProcess to start Uniface as a seperate program.

    Kind regards,

    Sjaak


    Author: sjaak (sjaak.van.schie@uniface.com)
  3. Hi,

    Thanks for the answers.

    @RogerW: I tried out some things with manifest files... this didn't help (perhaps I don't use manifest file correctly... I'm don't know that technologiy very well)

    @SJaak: Thank you. In fact, your hint made me progressing. In fact I discovered that there is a ULIB.DLL in System32 (Library shipped with Windows). It seems that this library was in conflict with the ULIB.dll coming along with Uniface... But unfortunately moving my app to Uniface's bin folder did not solve the problem, since I got another error that I wasn't able to solve ("callin.exe has stopped working" ... no further error message...). I've the feeling that this is still linked to the ULIB conflict story ... but after one day of investigations I have no clue how to resolve the problem.

    A strange thing I discovered: When I do a uniface call-out to callin.exe and then I do a call-in back to Uniface then it works !!!?!!!

    Any further suggestions/ideas?

     

    Kind regards,

    Kevin


    Author: palm.kevin (kevin.palm@labsolution.lu)
  4. Hi Kevin,

    this was the point of my "lost" reply to you:

    AFAIK, there was a problem startung a uniface virtual with unifbeg on PC platforms.

    Only when uniface was aready running, the URUN completed successfully.

     

    I think one of "the Lab"-crew can give us more details on that and if this is still a challenge.

    Success, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. Thank you Ulrich,

    Yes, this is still an issue.

    Notice that I discovered that I get the same error when using USETPARAM or UGETBIND methods...

    Notice furthermore that I even don't have to call those methods to make the application hanging: The application hangs while loading (only if one of the mentionned methods are referenced somewhere in my code...)

     

    Kevin


    Author: palm.kevin (kevin.palm@labsolution.lu)
  6. Hi,

    have you tested to use the "Call-in using the Call-in API".

    #include <uactdef.h>
    uecreate(...); /* Initialize the Uniface environment*/
    ueopen(...); /* Get an environment handle*/
    uinstnew(...); /* Create an instance of a component*/
    uopract(...); /* Activate an operation in this component*/
    uinstdel(...); /* Delete the component instance*/
    uedelete(...); /* Close the Uniface environment*/
    

    In "uecreate" giving the full path of your ASN-file:
    retCre=uecreate(1, 0, "", "C:\\uniface\\bin\\kiu9.asn", 0, 0, &hEnv);

    Regards RogerW.


    Author: rogerw (roger.wallin@abilita.fi)
  7. Hi RogerW,

    Yes, I tried that method, but unfortunately it is not possible to show a uniface form by doing so.

    This is due to the limitation that the uniface handle can only be created in batch mode (first parameter of UECREATE method).

    Thanks,

    Kevin


    Author: palm.kevin (kevin.palm@labsolution.lu)
  8. Dear Kevin,

    Please make sure that you are using at least the patch R103, since it fixes the following (3GL Call-In related) issue:

    Bug Report #28771 "UF94: Dynamic initialization of yrtl cause some C Call-In functions to fail"

    Symptoms:

     In Uniface 9.4 some things (like for example objects related to WEBLOAD) are
     dynamically initialized when the yrtl module is loaded. This change can cause
     problems for some Uniface C Call-In functions (like for example
     UGETREGS/UPUTREGS) since it seems to change the required order in which the
     dependencies are loaded - this results in a crash since objects are used before
     they are correctly initialized.
    
     The above described issue does not occur with previous Uniface releases (like
     for example Uniface 9.3).
    

    Hope this helps.

    With kind regards,
    Daniel

    *** Usual disclaimer ***

     


    Author: diseli (daniel.iseli@uniface.com)
  9. Dear Daniel,

    Your hint seems very precious.Unfortunately the patch seems not being available ("Page not found" when clicking on the patch-link of the issue site).

    I'll contact frontline support to get this link fixed.

     

    Best thanks,

    Kevin


    Author: palm.kevin (kevin.palm@labsolution.lu)
  10. Dear Kevin,

    You can download the version 9.4 patches from here:

    Hope this helps.

    Kind regards,
    Daniel

    *** Usual disclaimer ***

     


    Author: diseli (daniel.iseli@uniface.com)
  11. Applying the patch has fixed the problem.

    Thanks a lot!


    Author: palm.kevin (kevin.palm@labsolution.lu)
  12. Just to complete this issue: I found out how run the call-in application without having to copy it to the Uniface-bin folder.

    The initial problem is that, on runtime, the application loads the ulib.dll contained in the Windows system32 folder instead of the one contained in the Unfiface/Common/bin folder.

    To prevent this, I discovered the following solution (others exist...):

    1. When linking, add uniface libraries to list of dynamically loaded libraries (with Visual C++: /DELAYLOAD:"ulib.dll" /DELAYLOAD:"yrtl.dll" /DELAYLOAD:"ucall.dll" /DELAYLOAD:"urtl.dll")
    2. Then, at the beginning of the main function of your application, define the folder where dlls should be searched first: SetDllDirectory(_T("C:\\Uniface9401\\common\\bin\\"));
    3. That's it

    Author: palm.kevin (kevin.palm@labsolution.lu)