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.

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

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

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

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

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.

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

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 ***

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

Dear Kevin,

You can download the version 9.4 patches from here:

• ftp://ftp.compuware.com/pub/uniface/patches/9401/w32/

Hope this helps.

Kind regards,
Daniel

*** Usual disclaimer ***

Applying the patch has fixed the problem.

Thanks a lot!

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