Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VFP 'unresponsive' for 60 secs when closing MSCOMMLib.MSComm 3

David Higgs

Programmer
May 6, 2012
406
GB
My VFP application connects to my Amateur Radio Transceiver (via Serial COM Port 3) for CAT Control. CAT Control is a generic term used to describe how a PC can control the frequency and various other settings of a transceiver. The CAT commands are bi-directional. My application has run for a number of years without any ‘comms’ issues.

I’ve been looking at sharing the Transceiver (Serial COM Port 3) with VFP and another 3rd Party Application. I decided on using a Virtual Serial Port Emulator (VSPE) by https://eterlogic.com/products.vspe.html

I configured VSPE to allow my VFP application using Virtual Serial Port COM 10 to communicate with my Transceiver Serial Port COM 3. I intend using another 3rd Party Application on Virtual Serial Port COM 11.

When running VSPE, my VFP application (Virtual Serial Port COM 10) connects to my Transceiver (COM 3) and works as expected. However, I have an issue which I’ve not be able to resolve. When I exit my VFP application by clicking the ‘Exit Program’ Command Button VFP becomes ‘unresponsive’ for 60 secs before closing down.

VSPE Test

To eliminate any ‘code’ issues with my VFP application, I created a simple VFP Form with just three Command Buttons ‘Set Frequency 1’, ‘Set Frequency 2’ and ‘Exit Program’

I ran this VFP Form with no other Code, it opened and closed with no issues.

I then added an ‘ActiveX Control OLE Class MSCOMMLib.MSComm.1’ to the form.

I then ran the VFP Form again and when clicking the ‘Exit Program’ Command Button the application became ‘unresponsive’ for 60 Seconds and then closed.

The only time the problem (VFP being un-responsive for 60 Secs) seems to manifest itself is when I run VFP and VSPE together.

My VFP application works ok when connected directly to my Transceiver on Serial Port COM 3.

VSPE works ok with my Transceiver using other 3rd party applications.

Comms settings

Screenshot 2025-02-20 125149.png
Screenshot 2025-02-20 125249.png

Code:
* Command Button 1

thisform.transceiver.output = "FA003760000;"     && Set Transceiver Frequency 

* Command Button 2

thisform.transceiver.output = "FA007160000;"     && Set Transceiver Frequency 

* Command Button 'Exit Program'

thisform.transceiver.PortOpen = .F.    && Release Comm Port

thisform.Release
 
I created a TEST.PRG with the following code:

Code:
_SCREEN.AddObject("oComm","olecontrol","MSCommLib.MSComm.1")

An error message says: Object Class is Invalid for this container.
 
Oh wow, _screen is a form just like, but I should have tried this before suggesting, sorry . Well, you could still put the MSCommLib.MSComm.1 control into any other form and start it once, never show that form it but use its MSCommLib.MSComm.1 control.

Perhaps use this simple class definition for it:
Code:
oCOMM = CreateObject("COMMform")
* COMM object now available as oCOMM.COMM.
Define Class COMMform as Form
   Add Object comm as Olecontrol With Oleclass="MSCommLib.MSComm.1"
Enddefine

I know that the winsock control license VFP has only allows Winsock to be used on forms, I did not think that's also a limitation of the MSCommLib.MSComm.1 control. Even when it's the same, _screen is a form.
 
Last edited:
Chris,

I understand your concept of using a ‘lone’ Form for the ‘Comms Object’, it is the implementation of it that I may struggle with, so please accept my apologies before hand if that should be the case.

I have the following code in MyComm.prg

Code:
PUBLIC oComm

DO FORM forms\comms_test

****************************************************

oCOMM = CreateObject("COMMform")
* COMM object now available as oCOMM.COMM.

* oCOMM.Show(1)
 
DEFINE CLASS COMMform AS Form
    AutoCenter = .T.
    Width = 300
    Height = 200
    caption = "Comms - Holding Form"
    
    ADD OBJECT Comm AS OleControl WITH Oleclass = "MSCommLib.MSComm.1"     
ENDDEFINE

I have the following code in the Init of my test app

Code:
    oCOMM.Comm.CommPort = 10
    oCOMM.Comm.Settings = "38400,N,8,1"
    oCOMM.Comm.PortOpen = .T.

When I run the .PRG file I get "Object oComm not found" error so I guess I'm not using the correct syntax?
 
Well, you first start your comms_test form and then create the COMMform into the oComm variable. So oComm is still just .F. - the inital value of a variable - not yet an object in your form init.

Do it in the right order:
Code:
PUBLIC oComm
oCOMM = CreateObject("COMMform")

DO FORM forms\comms_test
****************************************************
* ...

Even better would be you create the COMMform once in main.prg or somewhere else you do early and then use oCOMM.Comm anywhere you require using a com port.
 
Last edited:
I thought it might be something to do with the order of my code.

I made the alterations to the code as you suggested and the app worked as expected. I was able to change the Transceiver Frequency, able to exit the application and return to the VFP IDE without witnessing any ‘unresponsiveness’. However, when I tried to close the VFP IDE I encountered VFP being unresponsive again.

It would appear that until the real cause of VFP becoming unresponsive is identified and rectified the issue is not going to go away. It’s most likely to do with closing the comm port.

I think I will park this for now, it’s way beyond my ability to find a solution.

Thank you for all your help, it’s much appreciated.
 
However, when I tried to close the VFP IDE I encountered VFP being unresponsive again.
Of course, that was to be expected. But moving that lag to exiting the application (or VFP itself), what do you care? You want to exit. Just set _screen invisible before exiting and you don't see how long that takes. Even if you want to exit to restart VFP again, nothing hinders you to do that and the start of that is not bound to the exit finishing.

I agree, the problem is not solved, but since you can't put your finger on anything that takes the time, internally in the COMM control or the virtual COM port driver, there's nothing better to do, if the VSPE team can't help you then your only chances are looking for something else but their virtual port/driver or something else than the MS Comm control. But for now, you moved the time delay to exiting, I don't see it as a problem.
 
Chriss,

I hope you didn’t think I was being dismissive of your help trying to solve the issues I’m having with my application? Being a ‘Novice’ VFP programmer I very much appreciate the help I receive from you (and others) on this forum. I felt that we had investigated the issue as far as we could and that you provided a pragmatic solution until such time the issue can be resolved.

This thread has provided me with the confidence to (a) realise my application is not the root cause of the problem and (b) it has given me the confidence to present our findings to the authors of VSPE. To this end, I have made contact with the VSPE support team who have been very helpful and have identified an issue. They will hopefully provide a revised copy of VSPE in the next few days.​
 
I would try to get a replication of the problem in VB. or any other programming language able to use the MSCOMM32.OCX

If yougoogle for "COM Port programming withour MSCOMM32" you find that others have the same problem (and not much love for the MSCOMM32 OCX control) and it's doable with API Functions of the Kernel32.dll on the general topic of Overlapped I/O functions. I bet it's very low level and the best I found on that as a collection of user defined functions for VB is this:

On the oither hand specifically reproducing the problem with usage of MSCOMM32 I found besides using VB6 you could use OCXes in PythonQT, a minimal example is at https://gist.github.com/sunjerry019/e51504317f523c21ef12da5155c1354f using DATARAOCX.GetDataCtrl.1, but that coul dbe replaced with usage of MSCommLib.MSComm.1
 

Part and Inventory Search

Sponsor

Back
Top