13 replies to this topic

[Ross Bevin]

I only program in ProIV and have never called a dll from logic before. I have a question for those of you that are familiar with calling dll's. Is it possible to call a dll written in .NET? I have reviewed the documentation and from what I can see only dll's written in C can be called. Is this a correct assumption?

[mikelandl]

I only program in ProIV and have never called a dll from logic before. I have a question for those of you that are familiar with calling dll's. Is it possible to call a dll written in .NET? I have reviewed the documentation and from what I can see only dll's written in C can be called. Is this a correct assumption?

Hi Ross,

I have only briefly looked into this topic once in the past but I believe you can only use .ocx files which are non-.NET dll's. If anyone knows differently I would love to know as well.

[DARREN]

I only program in ProIV and have never called a dll from logic before. I have a question for those of you that are familiar with calling dll's. Is it possible to call a dll written in .NET? I have reviewed the documentation and from what I can see only dll's written in C can be called. Is this a correct assumption?

Hi Ross,

I have only briefly looked into this topic once in the past but I believe you can only use .ocx files which are non-.NET dll's. If anyone knows differently I would love to know as well.

Do you want to make the call from the client or from the server?

[mikelandl]

I only program in ProIV and have never called a dll from logic before. I have a question for those of you that are familiar with calling dll's. Is it possible to call a dll written in .NET? I have reviewed the documentation and from what I can see only dll's written in C can be called. Is this a correct assumption?

Hi Ross,

I have only briefly looked into this topic once in the past but I believe you can only use .ocx files which are non-.NET dll's. If anyone knows differently I would love to know as well.

Do you want to make the call from the client or from the server?

In my case it would be from the client (all of customers run Linux servers).

[Ross Bevin]

I'm making the call from the client, using "LINK_CLIENT_VAR", as the dll returns the Citrix username where the client is running on. I haven't got it to work yet because (a) our non ProIV developers don't understand what the ProIV manual is telling them to do to prepare the dll for use by ProIV and ( it's written in .NET.

[DARREN]

I'm making the call from the client, using "LINK_CLIENT_VAR", as the dll returns the Citrix username where the client is running on. I haven't got it to work yet because (a) our non ProIV developers don't understand what the ProIV manual is telling them to do to prepare the dll for use by ProIV and ( it's written in .NET.

Yep. We struggled a bit with the documentation but one of our developers worked it out. Here is an example of our LINK_CLIENT_VAR code. I will ask the developer if he can write something up from his side that may clarify things a bit more. As previously mentioned in another thread, will will be removing a Windows specific code and replacing it with SSO's and/or JavaScript controls. That is why we currently have a Session.DisplayType test around it.

//

PARMS($ENTITY_TYPE,$ENTITY_ID,$TITLE,$AUTOADD,$SUBJECTSEQ,$NOTEKEYSEQ)//IF Session.DisplayType = 'WINDOWS_CLIENT' THEN   $SESSION = GETCOM('SESSION')   $OPERATOR_ID = ''   $PROIV_OPR = ''   $NOTES_PORT = ''   #LOOP = 0   //   // get the PROIV oper code for the session   //   GLOBAL_LSCALL(RM0100L2,1001)   //   IF $PROIV_OPR = '' THEN      MSG(2,$SESSION,$PROIV_OPR)   ELSE     //     $NOTES_PORT = GETCOM('NOTESPORT')     //     $ENV = &$ENV     //     CALL 1     //     IF #RESULT # 0 THEN        IF #RESULT = 7 THEN           //           $RETRY = 'Y'           WHILE $RETRY = 'Y'              #LOOP += 1              IF #LOOP > 1 THEN                 $RETY = ''                 IF #RESULT # 0 THEN                    MSG(1,@FUNCT + ' ' + CONV(#RESULT))                 ENDIF              ELSE                 //                 //                 CALL 1              ENDIF           ENDWHILE        ELSE           MSG(1,@FUNCT + ' ' + CONV(#RESULT))        ENDIF     ENDIF   ENDIFENDIF:1IF $AUTOADD = 'Y' THEN  //  #RESULT = LINK_CLIENT_VAR('ppsnotes.showNotes',%IN% $NOTES_PORT)  #RESULT = LINK_CLIENT_VAR('ppsnotes.newNote',%IN% $ENTITY_TYPE,%IN% $ENTITY_ID  ,%IN% $PROIV_OPR,%IN% $ENV,%IN% $TITLE,%IN% $SUBJECTSEQ,%IN% $NOTES_PORT)ELSE  #RESULT = LINK_CLIENT_VAR('ppsnotes.loadEntity',%IN% $ENTITY_TYPE,%IN% $ENTITY_ID  ,%IN% $PROIV_OPR,%IN% $ENV,%IN% $TITLE,%IN% $SUBJECTSEQ,%IN% $NOTEKEYSEQ,%IN% $NOTES_PORT)ENDIFRETURN

[Ross Bevin]

Hi Darren,

Thanks for the code example. The problem is more with this documentation below. My .NET DLL developer doesn't really understand what he has to do on the ProIV Environment side to publish the dll. I did get a reply back from Northgate this morning telling me that .NET dll's are not supported by ProIV. So I either get my developer to rewrite it in C or better yet, in ActiveX.

Regards
Ross


Writing the extsub.c Module

Virtual Machine

Trail: PROIV Documentation > Administration > Environment Guide > Writing the extsub.c Module

The extsub.c module determines the subroutine to be called from the Name Table, and calls the appropriate routine.

If you are supplying your own extsub.c module, it is recommended that you use the extsub.c module provided and modify it to suit your purpose.

The following rules must be followed for extsub to link and run with PROIV:

·The name table for the logical subroutine name must follow the same format as that supplied in extsub.c.

·The variable nsubs must be declared in the extsub.c module. It should be initialized to the number of subroutines in the table.

·A function extsub( ) must exist and take parameters of the type defined in the extsub.c module provided.

[DARREN]

Hi Darren,

Thanks for the code example. The problem is more with this documentation below. My .NET DLL developer doesn't really understand what he has to do on the ProIV Environment side to publish the dll. I did get a reply back from Northgate this morning telling me that .NET dll's are not supported by ProIV. So I either get my developer to rewrite it in C or better yet, in ActiveX.

Regards
Ross


Writing the extsub.c Module

Virtual Machine

Trail: PROIV Documentation > Administration > Environment Guide > Writing the extsub.c Module

The extsub.c module determines the subroutine to be called from the Name Table, and calls the appropriate routine.

If you are supplying your own extsub.c module, it is recommended that you use the extsub.c module provided and modify it to suit your purpose.

The following rules must be followed for extsub to link and run with PROIV:

· The name table for the logical subroutine name must follow the same format as that supplied in extsub.c.

· The variable nsubs must be declared in the extsub.c module. It should be initialized to the number of subroutines in the table.

· A function extsub( ) must exist and take parameters of the type defined in the extsub.c module provided.

The documentation example looks like it relates to the calling of external subroutines from the Kernel via the LINK command and not the LINK_CLIENT_VAR. I know that the dll we use resides on the users c:\windows\systems32 directory as this is the second place the client looks for the dll if it does not find it in the client install dir.

[Ross Bevin]

Hi Darren,

Are you saying that if I have a dll that I want to call from the client side with LINK_CLIENT_VAR, all I need to do is copy it to C:\Windows\System32?

Thanks
Ross

[DARREN]

Ross,

Not sure if you found a resolution to this, but one of our programmers here got this resolved. I have pasted the code below. Obviously this is only applicable to the Windows Client and as such you would need to use JavaScript/Json for Open Client or SSO's if it can be done server side. I would therefore suggest that this only be used as a stop gap solution (if at all) untill you are on OpenClient/Version 6.2


[codebox]I was able to get a pass-thru to .NET from ProIV using COM.

You create your Class library in .NET

namespace Foo
{
public interface IFoo
{
void bar();
};

public FooClass : IFoo
{
public void bar()
{
MessageBox.Show("Hello from .NET");
}
}
}

You need to update the AssmbleInfo.cs

[assembly: ComVisible(true)]
[assembly: AssemblyDelaySign(false)]

And sign the assembly (Project Properties, Signing).
Build your library (DLL) and RegAsm

RegAsm Foo.dll /tlb:Foo.tlb /codebase

Then you can use C++ COM interface to hook ProIV in to the .NET code.

// foobar.hpp
extern "C"
{
__declspec (dllexport) int FAR WINAPI foobar(short _nArgs, char* _pszArgs[]); }

// foobar.cpp
#import "Foo.tlb"
using namespace Foo;

__declspec (dllexport) int FAR WINAPI foobar(short _nArgs, char* _pszArgs[]) {
HRESULT hr = CoInitialize(NULL);
IFooPtr pIFoo(__uuidof(FooClass));
pIFoo->bar();
CoUninitialize();
return 0;
}

Add and extra link command /export:bar

Build your C++ DLL, this will be used by ProIV with LINK_CLIENT_VAR.
Place the C++ in your Northgate/Client folder or System32

Basically what you end up with is a .NET DLL with full access to the .NET Framework. That is called via the COM interface you provide through the unmanaged C++ DLL.

You'll be shipping two DLLs. The .NET DLL will need to register it's assemblies with the local machine you wish for this to run on.
[/codebox]

[Richard Bassett]

Now that's what I call support

As Darren says, extsubs relates to linking code with the kernel and calling it via LINK(). What the docs say about that is mostly econo9mical with the truth too but let's not get into that..

Edited by Richard Bassett, 12 March 2010 - 09:30 AM.

[Ross Bevin]

Hi Darren,

Thanks for this; it may come in handy for other problems that come up. What I was trying to use was a .NET program that authenticated a Citrix logon. In the end the non ProIV developers put it inside a .exe for me. Yes, I know we will have to start looking at JavaScript if we plan on moving to OpenClient.

Thanks
Ross

PS: Yours and other postings around DDE and Excel were very helpful to me the other day. I was able to garner all the info I needed to get reports outputting to Excel with full formatting. Thanks for these posts too!

[DARREN]

we are activley looking for methods to remove our DDE code as it relies on client side processing. I have contacted Wim, as i know he has achieved this with XML and the XMLFOP and xsl. He is going to send me a demo function.

If anyone has another method to remove DDE dependency then I would be very interested to here about it...like the ResourceLink guys for example.

[deepghosh]

we are activley looking for methods to remove our DDE code as it relies on client side processing. I have contacted Wim, as i know he has achieved this with XML and the XMLFOP and xsl. He is going to send me a demo function.

If anyone has another method to remove DDE dependency then I would be very interested to here about it...like the ResourceLink guys for example.

XMLFOP became obsoleted technology because of difficulty of use.

You may try jasper for java side or MS Reporting tools for (Windows).