13 replies to this topic

[luser]

Hello all:

The company I work for uses Glovia-- I'm one of the users, not a developer.

Some of the data-entry tasks my department is responsible for are quite repetitive and could be automated to a large degree. I've done some thinking into how I might do that: I've considered using a screen-scraping approach through a telnet session, but it seems like using a COM instance of the client might be simpler and more reliable.

The problem is, I'm having trouble getting started. I thought I'd use VB to play around with at first-- I've embedded the ProIVClient OCX into a VB form, but from there I can't even guess what syntax to use to make the control connect to the server, much less receive & send data.

Can anyone give me a nudge in the right direction or point me to some documentation on the use of this control?

[luser]

Oy-- the silence is deafening me!

Can I at least get a volunteer to tell me they've never used this control and aren't aware that any documentation exists?

[Mike Nicholson]

Hi luser (rather unfortunate name I must say ;-)

Not something I've tried but the documentation is in the PROIV Bus manual - do you have the manuals? This covers properties and methods for the OCX.

In order to seither send or receive information from the ProIV system I think you'll have to create a task. The methods then allow you to call the task while setting input parameters and reading any output parameters returned by that task.

As to whether it works - no idea !! Anybody here tried it?

Cheers

Mike

[MarkIV]

luser,

We have created a VB OCX and used it in the PROIV application,
sort of your idea in reverse.

[luser]

Folks, my apologies on making a comment about getting a slow response and then taking forever to reply back when the responses came. I picked a pretty bad time to ask for help-- I've had a major project going at home, and my off hours are the only time I have to work on this.

I'll try digging a little deeper using the ProIV Task OCX API documentation in the Bus manual, but the impression I got from the manual is that particular control is to be used on the server side of things and is there to provide a language independent way of defining tasks.

The file name of the control I'm looking at is ProIVClient.ocx: my hope is that it can provide me with an embeddable client that I can control programmatically, strictly client-side activities. I would not want to ask the Glovia programmers to make any additions on the server side to accommodate me. For one thing, I seriously doubt they would do so, and for another it would probably make me a little uncomfortable if they did anyway. Right now I know what access is granted to my group in the tasks I'm hoping to automate. It would probably worry me about unintended consequences if things were changed on the server for this.

--and the name was intentional ;-) I wanted to be up front that I'm a user rather than a programmer, and I thought a little humor might help to grease the skids with you guys. Also, I kind of like that ProIV seems to have a lot of roots in Unix land, so "luser" seemed fairly apt--

[luser]

(This is long, if you want to skip down to the punch line read the final sentence)

OK, I've done some more tinkering. I still haven't met with success, but I'm convinced I'm on the right track. The ProIVClient.ocx file is almost certainly an ActiveX version of the ProIV client: in other words, it's exactly what I want. The methods and properties available in the control match 1:1 with settings presented in the "Options" dialog and with other ProIV Client actions and events.

It seems to me the closest thing to documentation for this control is the "Windows Client User Guide". Chapter 3 ("Establishing Connectivity") names the settings in the Options dialog that are necessary for establishing a connection from the client. I've gone through the steps listed in that section and successfully established a connection from the client--
--set host to xxx.xxx.xxx.xxx
--left port set at 23
--checked the "Login via terminal" radio button
--terminal command is "telnet"
--Set a terminal window title
--left terminal type as "PROIV"
Once I enter those settings, I'm able to hit the "Connect" button & things work as expected.

So now I'm trying to duplicate those steps in Visual Basic. I've inserted the client control into a form and put in the following code to set the essential properties:
ProIVClientOCX1.LocalKernel = False
ProIVClientOCX1.HostName() = "xxx.xxx.xxx.xxx"
ProIVClientOCX1.HostPort() = "23"
ProIVClientOCX1.TerminalCommand = "telnet"
ProIVClientOCX1.TerminalTitle = "Telnet to test environment"
ProIVClientOCX1.TerminalTypeWanted = "PROIV"
ProIVClientOCX1.TerminalPort = "3682"
ProIVClientOCX1.EnableSingleClick = True

I don't know if I've entered those properties correctly or not, because I haven't been able to execute the "Connect" method!!!!

VB's Object Browser has the following to say about the Connect method:
Sub Connect()

And a freeware ActiveX control browser I found says this--
void Connect()

Neither seems overly informative, but both seem to indicate that the method doesn't take any arguments-- I would think I should just be able to call it when I'm ready and it will try to make a connection per the previous property settings.

No such luck, though. When I try the following--
ProIVClientOCX1.Connect
--I get a "Run-time error 449: Argument not optional"

I've tried adding random strings as arguments to see if any clues will pop up--
ProIVClientOCX1.Connect ("asdf")
--and I get "Compile error: wrong number of arguments or invalid property assignment"

Please—if anyone out there has knowledge or just an educated guess on how I’m supposed to call the “Connect” method, you will have my undying gratitude…

[Rob Donovan]

Hi,

Create a form, and put the ProIV ocx on it and put the following in the forms Load event...

ProIVClientOCX1.AskBeforeConnect = True
ProIVClientOCX1.LocalKernel = False
ProIVClientOCX1.HostName = 'YourMachineName'
ProIVClientOCX1.PromptForSecurity = False

ProIVClientOCX1.Connect

And to run a function....

ProIVClientOCX1.SendInputToKernel "ROBMENU"
ProIVClientOCX1.KeyReturn

If you have a user/password to enter, then you must set the following after the AskBeforeConnect line...

ProIVClientOCX1.UserName = "name"
ProIVClientOCX1.Password = "pass"

HTHs,

Rob D.

[luser]

Hello Rob:

Just to be safe I tried starting fresh, hopefully following your instructions exactly. Previously I've been working with VB 5.0, so on the off chance that my problem was due to using such an old version I used the Visual Basic Editor in Excel 2000. In case it's of any interest, the operating system is XP Professional.

Here's what I did, step by step:
--Created UserForm1
--"Tools" menu--> "Additional Controls"--> checked the "PROIV Client" checkbox
--dragged the control from the toolbox onto UseForm1
--Typed in the following for UserForm_Initialize() (VBA doesn't support the LOAD event, but I get the same results anyway)

Private Sub UserForm_Initialize()
    ProIVClientOCX1.AskBeforeConnect = True
    ProIVClientOCX1.LocalKernel = False
    ProIVClientOCX1.HostName = "ProivServerIPAddress"
    ProIVClientOCX1.PromptForSecurity = False
    ProIVClientOCX1.Connect
End Sub

--and I still get the "Argument not optional" error when I try to run the form. This happens whether or not I set the Username and Password properties.

One thing that may be worth noting is that this is the first time I've ever tried to use an OCX for anything. When I first tried to put the control into a form I kept getting an error until I finally used an account with administrative rights to insert it. I never made any changes to the registry to formally register the control, but it does show up in the list of available additional controls now.

Rob, I appreciate your reply and I assure you I will gladly accept any help you care to offer. However, I see that you are member #1 of this forum, which tells me that if you aren't the founding father of this site then you are probably his brother. This is almost a little troubling to me,

[luser]

--whoops! a little too quick on the "Add Reply" button there...

Anyway Rob, what I was saying is that this might end up being a case of using a cannon to kill a fly. In all probablility, when the solution to my current problem becomes apparent, it will end up with me slapping my head & yelling "Duh!" Most likely, the main issue here is the footing of supreme ignorance I'm starting out from.

Fair warning, and again, many thanks for the reply.

[luser]

An update--

I guess I do have some problem somewhere in the ActiveX chain for the control. I've repeated my earlier steps on a different machine & have gotten past the initial phases. So far I've gotten to the point where username and password are sent to the server when I get the following error message:
"Unknown protocol offered by PROIV kernel, expected 68, offered 35."

[luser]

Thanks Arm_Chair:

Actually, I've been able to view the guts that the control exposes using the VB IDE since I started experimenting. My original hope was that there would be some documentation I just wasn't aware of that spells out the usage of the control. By this time I'm pretty sure there's no such documentation.

I was able to make an initial start on using the control by following some of the documentation for the Windows client, though. Most of what I've posted in this thread is about the problems I had getting to that point. The first problem I was having was (I think) due to something getting scrambled in the registry on my first attempt to embed the control. If I had ever had previous experience using ActiveX controls I probably would have recognized what was going on from the start and you guys could have been spared a lot of my tears.

The second problem-- the message about the kernel offering a different protocol than the client expects-- pretty much seems like a brick wall. Getting that error was a fairly crushing blow to my morale in this little project...

Folks, I hate to say so after I've made so much noise in this forum, but by this time I've pretty much decided to pursue my first idea of writing an interactive program that works by screen-scraping a "green screen" Glovia session. It seems to me that if I go that route I will greatly reduce the number of things I have to try to use that I can't control or even study beneath some black-box type surface.

As it is, I have no way to control how the server negotiates a protocol to communicate with the OCX client. I also don't see any way to guide the client through a negotiation, and the error I got suggests to me that the client control wouldn't even recognize some of the server's communications if I could do so. If I was really motivated, and had complete documentation of server protocol 35 and client protocol 68, I might try to make some sort of middleman program to sit between the client and server to act as a translator between the two. That sounds like it would be bending over backward to try to use a tool, though, even if I had documentation for the protocols. And I haven't found any kind of documentation for the protocols

By making a screen-scraping interface, the only thing that's really closed off to me is how the server itself is coded. I'll be doing my programming in Python, and the communication protocol is telnet-- both of which are documented and open for me to examine down to whatever minutia I can tolerate. The Glovia kernel would then be the only black box I'd have to worry about.

I'll be tinkering with that approach for the next little bit. I won't bother the people in this forum with the problems I'll run into doing screen scraping, since this isn't the place to discuss that sort of thing. If I get to the point where I'm comfortable that everything's working the way I like it, I'll probably post back with a quick "it works". I'll probably also check this thread every now and then on the off chance that someone out there knows how to make the client speak fluent "protocol 35"

For now, I do appreciate everyone who's offered me their help, hints, and thoughts. 'Till next time, hope life treats you wonderfully!

[Mike Nicholson]

Just for those people using it...

Apparantly ProIV are no longer supporting the OCX or including it with new releases.

Cheers

Mike

[JamesS]

A most interesting thread on the PROIV Client OCX.

I thought it worth setting the world straight on where we are with the MFC Client and ActiveX.

First a bit of history; the MFC Client was created using the Microsoft Foundation Classes 4.2 - circa end 1996 - it was built with Visual Studio 6.

PROIV created an OCX build of the PROIV MFC client summer / autumn 2003 so we could deploy the PROIV client within a webpage - this being the birth of the WebClient product. At this point we never (I hate using this word - how about to my knowledge!) released any programmers documentation for the PROIV Client Control. I accept any VB or C++ developer could easily discover its methods and properties using a suitable IDE - and some people did.

Approximately this time last year we began to experience some support issues with the MFC client when it was embedded in IE and also stand alone. These were primarilly around the use of activeX controls in the client.

This coincided with our decision to move C/C++ development envronments from VS 6 to VS.NET. We had to do this as MS have EOL support on VS6 (just as they have done on VB). See http://support.micro.../lifedevtoolfam. Note VB 6 was EOL at the end of last month

To resolve the activeX issues we needed to upgrade the client codebase to the latest VS.NET (2003), this also allowed us to rationalise the code base so we only built ONE client, an activeX control. Now you will see that the MFC client application is very thin 30Kb - its role is to launch the PROIV client control. THis also gives us the ability to launch the client from IE - but more importantly not embedded within IE. As part of this we did rename the control - but we did leave the GUID the same.

For the record we are now actively investigating VS .NET 2005.

We also adopted the MS versioning convention; rather than build 524 for example we now use 5,6,x,y where X is revision and y is patch. Generally all PR versions of the client should end in a 0 - as you can see the current client is 5,6,5,0.

So let me be very clear (and I should know) the MFC client as an ActiveX control is here to stay. With some of the developments we are planning we will be using it ourselves as a control and will be productising its interface. I am unable to give a timescale or details on the level of productisaion - but it is in the near future.


James Sanderson