I have a .NET control that I am using to access serial ports from an RBasic stored procedure. When I run in the SYSPROG application everything works correctly and I can read the serial port. However when I run the same procedure my user defined application the startdotnet command fails.

dotNetHandle = StartDotNet(DotNetCtl)

The above command returns an Idispatch handle under SYSPROG but in the user app returns a popup box with the following:

ENG0016: STARTDOTNET, Line 1. Non-numeric data when numeric required. Zero used.

Since the initial call to start dotnet fails, it's not even getting to my serial port control. Any guidance would be appreciated.

thanks in advance.

Hi, Brad. Can you show me some more of your program? Specifically, the lines before the StartDotNet call? I would like to know how DotNetCtl is set, or any other DotNet calls you're making before the one that "blows up".

Thanks!

- Bryan Shumsky

Revelation Software, Inc.

DotNetCtl is unassigned. I have tried assigning a value to DotNetCtl but whem I do StartDotNet returns an empty (in both SYSPROG and the client app). Keep in mind this control is not tied to any form fields and the subroutine is a low level module is called from multiple places so there is not "control" to tie the start to..

Subroutine xx_serial_test (void)

*

* Move attached application tables to new folder structure and database

*

*

   $Insert REVDOTNETEQUATES

   $Insert Logical

*

   Declare Function CheckDotNet

   Gosub SComm

return

*

SComm:

   equ  comNone$       to 0

   equ  comXOnXoff$    to 1

   equ  comRTS$        to 2

   equ  comRTSXOnXOff$ to 3

   Equ  boolFalse$     To 'FALSE'

   equ  boolTrue$      To 'TRUE'

   sConfig = "9600,n,7,1"

   comport = 1

debug

   dotNetHandle = StartDotNet(DotNetCtl)

   If Get_Status(errs) Then

        Gosub handleError

   End

   debug

Hi, Brad. Thanks for that. It doesn't "blow up" when I just use that snippet of code in a test program, both from SYSPROG and from an inherited application; but that's testing it on my development system. I will retest on one of the test installations of the new 10.0.8 and see if I can recreate the issue.

Was this a 10.0.8 "full install", or a 10.0.8 "update" that you ran?

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Update.

Update.

I've just tested on a copy of the "distribution", and I can't make it fail there either.

The fact that it runs from SYSPROG tells us that the .net assemblies are installed.

How are you launching SYSPROG vs your client app? Do you have shortcuts to both? If you log in to SYSPROG (and show that it works), and then use File/Open/Application to get into your client application, does that make any difference?

And just to be clear - when we say "client application", this is another application in the same copy of OI, right?

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Is it possible that an older copy of $STARTDOTNET was added to the local application (e.g., $STARTDOTNET*AppName)?

Don Bakke

SRP Computer Solutions, Inc.

To wrap up this topic (…for now?), Brad also tested in a new app, and didn't experience the problem. He then did an appbackup, deleted the application, created a new application, and did an app restore…and the problem didn't happen any more. I don't have any explanation as to what might have gone "wrong" with the application in its original incarnation, but for now we can only consider it a "one time anomaly" unless we hear about it happening again.

- Bryan Shumsky

Revelation Software, Inc.

View this thread on the Works forum...