Jump to content


Photo
- - - - -

Calling .NET dll's from logic


13 replies to this topic

#1 Ross Bevin

Ross Bevin

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 226 posts
  • Gender:Male
  • Location:Manzanillo, Colima, Mexico

Posted 07 October 2009 - 04:53 PM

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?

#2 mikelandl

mikelandl

    Expert

  • Members
  • PipPipPipPip
  • 101 posts

Posted 07 October 2009 - 05:28 PM

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.

#3 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 395 posts
  • Gender:Male
  • Location:Florida,USA

Posted 08 October 2009 - 01:28 PM

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?
Things should be made as simple as possible, but not simpler

#4 mikelandl

mikelandl

    Expert

  • Members
  • PipPipPipPip
  • 101 posts

Posted 08 October 2009 - 03:40 PM

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).

#5 Ross Bevin

Ross Bevin

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 226 posts
  • Gender:Male
  • Location:Manzanillo, Colima, Mexico

Posted 08 October 2009 - 04:07 PM

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 (B) it's written in .NET.

#6 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 395 posts
  • Gender:Male
  • Location:Florida,USA

Posted 08 October 2009 - 08:44 PM

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 ( B) 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

Things should be made as simple as possible, but not simpler

#7 Ross Bevin

Ross Bevin

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 226 posts
  • Gender:Male
  • Location:Manzanillo, Colima, Mexico

Posted 08 October 2009 - 08:59 PM

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.

#8 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 395 posts
  • Gender:Male
  • Location:Florida,USA

Posted 08 October 2009 - 09:04 PM

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.
Things should be made as simple as possible, but not simpler

#9 Ross Bevin

Ross Bevin

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 226 posts
  • Gender:Male
  • Location:Manzanillo, Colima, Mexico

Posted 08 October 2009 - 09:08 PM

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

#10 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 395 posts
  • Gender:Male
  • Location:Florida,USA

Posted 11 March 2010 - 10:56 PM

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]
Things should be made as simple as possible, but not simpler

#11 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 12 March 2010 - 09:30 AM

Now that's what I call support :lol:

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.

Nothing's as simple as you think

#12 Ross Bevin

Ross Bevin

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 226 posts
  • Gender:Male
  • Location:Manzanillo, Colima, Mexico

Posted 12 March 2010 - 01:43 PM

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!

#13 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 395 posts
  • Gender:Male
  • Location:Florida,USA

Posted 12 March 2010 - 06:52 PM

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. :lol:
Things should be made as simple as possible, but not simpler

#14 deepghosh

deepghosh

    Member

  • Members
  • PipPip
  • 37 posts
  • Gender:Male

Posted 25 June 2010 - 09:10 PM

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).





Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users