3GL: same function in 2 dlls?

Author: zdenek.socha@fullsys.cz (sochaz)

Hello,

we have several functions implemented in our dll (and we use them as 3GL call-out). Now, we want to migrate our dll to a new format with Unicode functionality and parameters. We have a signature like OURDLL, which is defined as C implementation, and set DLL name (in the signature) to ourdll.dll. Now we added a new dll named ourdll2.dll, defined a new signature OURDLL, with C implementation, character set used is UTF-16, and at this signature we defined a DLL name to ourdll2.dll. It is obvious, that both dll's have the same functions, only character set differs... we want to test both and call functions from both dll's.

Now, it seems that Uniface activates functions from the last dll defined in .asn file in [USER_3GL] section. Do you know, what's going wrong here? How else we can tell Uniface, which dll we want to call? We have 2 different dll files, we have 2 different signatures, at each signature we tell, in which dll it is located, we have both dll files in .asn file, but upon callin activate.... the last dll is activated, not the correct one.

I can't see anything in ulibrary.... currently we use this in Uniface 9.3.

Regards,
Zdenek

5 Comments

  1. Hi Zdenek, For better or worse, this is how Uniface works. There is an internal table mapping function names to DLL's, and a function can be in that table only once. When you have two [USER_3GL] lines for the a function, both are put in that table, but because the function name is the same, the second will overwrite the first. So when you activate the first signature you actually call the second DLL. Now, when you specify the DLL name in your signature, a [USER_3GL] line is not needed. So you can leave that out. Unfortunately that does not solve the problem... Now when you activate the first signature, it will correctly call the first DLL, but when you call the second signature, the function is already in this internal table so it will once more call the first DLL. Personally I think that when the signature specifies a DLL it should always call that DLL, instead of relying always on that internal table. This would probably be considered an enhancement. For now, you will have to work your way around it. Cheers, Chris


    Author: None (None)
  2. Hi Chris,

    thanks for that info.

    In V6/7, I heard (grapewine) if one start a perform, the listed DLLs are opened in sequence until a matching proc is found.

    the other DLLs are not opened for performance reasons unless another perform longs for an entry not found so far.

     

    But things have changed now as I got from your lines. Tnahks for this info and all best wishes for the amsterdam people.

    Hope to hear more from you and your colleagues on this forum next year, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  3. Hi Uli, I'm not sure how V6 and V7 worked. That's a looong time ago.... and not very relevant by now. Since we started using dynamic loading in V8, these things have changed big time. Indeed I don't visit this forum as much as I should. But this one caught my eye :) Cheers Chris


    Author: None (None)
  4. Hi Chris,

    thanks very much for that info, it's much clearer now, how it works and why. We know, this problem using perform, that's why we switched to signatures and activate.

    I agree, that activating function via signature with defined dll name should always call the function in that dll. Now it seems, we try to rename new functions and be extra careful with naming, since we use e.g. kernel32.dll, shell32.dll and other system libraries with function, so if we name our function the same as in OS dll, it will make quite unexpected results.

    Regards,
    Zdenek


    Author: sochaz (zdenek.socha@fullsys.cz)
  5. Hi Zdenek, I'm glad my reply clarified some. About ignoring the [USER_3GL] when a DLL is specified in the signature, that might not be an easy change. Probably quite a project, actually. If this is real important for you, you should submit it in the wish list right here and try to get some votes. Cheers, Chris


    Author: None (None)