Creating a non-ui class based on a .net component

HELP!

Ok, I'm stuck here, facing a blank wall. I have a

.net component that has no UI (ipworks xmpp control)

and I want to create a ABL class wrapper for it. Or

I want to be able to use the control without

having a form. (I am trying to use this component

within an appserver session).

How do I go about this ? The control is

nsoftware.IPWorks.Xmpp

I've created ABL classes for use in a visual object's Tag property. The Tag takes any object of type System.Object, and I've used a class that inherits from System.Object (which is non-visual).

class MyWrapper inherits System.Object:

def private temp-table ttBlah ....

end class.

I've noticed that doing so is more expensive than using a class that inherits from PLO (which is the default), but in certain cases I've needed to do it.

Is the Xmpp class a final (sealed or static) class?

-- peter

I am trying to use this component

within an appserver session).

It's been pointed out to me that my previous post might imply that you can access .NET from an AppServer, when, in fact, you can't.

Sorry for any confusion caused.

-- peter

My heart sinks. The ABL cannot create any .net classes (non-visual, of course) in an appserver session ? Why on earth not ?

Probably because the powers that be couldn't imagine wanting to use this capability for anything except UI, despite feedback in sessions I have attended at Exchange which indicated that there were people who did want to use it for something besides UI and in fact that might be their primary use.

This has been developed as "Advanced GUI for OpenEdge" and will be released as "OpenEdge GUI for .NET".

Progress only has Windows clients but AppServer on various platforms. I really like the fact, that AppServer code is platform independent. The usage of .NET classes on the AppServer would certainly breat this platform independentness.

That is certainly a good point, Mike. I myself would not want to use .NET components on an AppServer because I wouldn't want to have to use Windows for the AppServer. But, there are people who are willing to do that ... even wanting to for some reason ... and I think one can make a case for the concept being useful. Of course, if it was added, then the rest of us would be upset because it was another case of something being possible in Windows which was not transportable!

there are lots of things in .net that are not UI specific but could be utilized : for example the arrays - we could use them in the gui client but not appserver - just doesn't makle sense.

Meaning that you have a business case for non-UI .NET other than AppServer? Yes, I think that was a point a number of people were making in the session in Phoenix that I was thinking of. I think there are really two separate issues. One, is there a meaningful use case for non-UI .NET access in the GUI client? I'm pretty sure the answer to that is yes. Two, if in the client, should it also be in AppServer? Clearly, for you it should, but it would do me no good, so I would rather we got support for Java in addition to .NET instead. And, my interest there would be primarily for non-UI and would definitely include AppServer.

BTW, I should also note that my memory of this same session included the understanding that ABL GUI and .NET GUI would have to be separate windows, so discovering that they have figured out how to host ABL GUI in a .NET form means we have been given more than was then promised.

you know, it never occurred to me that the .net would not work with the standard progress char client. I just thought that it was appserver (non-ui) clients that had the problem.

I just checked and tried to compile a program with the char client.

def var a as system.array

and it didn't compile

Don't get me wrong. I would not mind the support for .NET access on the AppServer or for heavens sake a TTY client - but it's very low on my priority list.

But for the use cases, I believe we should separate two different categories.

Array and collection support (your desire for System.Array and the like) is something that should be added to the ABL natively. Without the need to use .NET for this. My understanding with the 10.2A bridge is, that it performs really great, but still has some costs. So for data management, the goal should be to remain ABL centric to avoid crossing the bridge (and to maintain platform independence).

You also mentioned Jabber (or something similar). If you want to access those non-UI classes, I believe this is because the .NET API is just so much more powerful than the abilities you have from the ABL directly. For as long PSC does not support this, I guess COM-Interop will provide you with the tool to access these .NET classes as COM objects (automation servers). COM-Interop is pretty easy when you do not require event support. That's possible as well, but a little bit more work (requires Interface declarations etc.). But since event driven programming on the AppServer is something that does not work too well we can ignore this fact.

I've been using COM-Interop on the AppServer and the 10.1 GUI client quite successful. It requires a MS development environment and very little coding, but it works very stable and performs good. It does not allow you to pass a refeerence to an ABL object to a .NET class, but that should not be required for accessing APIs anyway.

The focus on .NET UI is not an arbitrary one. Yes, I have received feedback supporting .NET objects other than UI and other than the GUI client. However, there is some danger in providing generic support for .NET. The two specific items I am concerned about are performance and threads.

When you want to use .NET collections in the ABL to hold ABL objects/data, the performance must be considered. Since the data from the ABL used with a .NET object always has to be marshaled to and from the .NET CLR. This is probably not a good general purpose solution especially for large collections. Additionally, all of your ABL classes would have to inherit from a .NET super class which means you would always have to cast to the ABL type to use an item from the collection. Again, not one of the fastest operations going. Native collections in the ABL is on our OO roadmap.

Now on to non-UI objects and threads. In the UI, there is a single UI thread that is used on a Windows machine. Even if controls do some work in a separate thread, all UI processing is expected on the main thread. This provides a nice mapping to the AVM which is single threaded. Once you get into general .NET objects, threading implementations are much more varied and have a higher probability of not working with the AVM. Now we could get into the discussion of multi-threading the AVM but its certainly not an option for 10.2A.

-Shelley

Now we could get into the discussion of multi-threading the AVM

Yes, please!

+1

While I agree that collections should be done natively in ABL and that multi-threading the AVM would be a great thing, it was also clear to me in that session at Phoenix that there are a number of people who feel like they have a use case for non-UI components, so I don't know that we should dismiss the need simply because the expression of need here happened to relate to possible use for collections or an AppServer use.

To be sure, not being a Windows guy, I would much rather you added capabilities to ABL ... especially if they are cross platform instead of Windows-centric. And, to be sure, if people are asking for this capability with .NET in order to get around some limitation in ABL, I'm not likely to find the .NET solution a good one since I am going to want to run it on a server, which won't be Windows.