Update to FAQ in RASOCX version 1.1

I am having trouble using Visual FooxPro and the RAS Control?

We have been working with engineers at Microsoft on the Foxpro development team, that worked on OLE support. Here is the current story
on using Visual FoxPro with the RAS Control.

First - 3.0b did a poor job of OCX support. At least one known problem is that both VFP 3.0b and 5.0 cannot handle events all the time;
unlike other container apps like VB, Access etc., which if they are busy queue events then display them, if VFP in either version gets an
event at times it cannot handle it, it is lost. Most of this seems to stem from VFP's roots in a language that is not multi threaded.

There is no known way to get around this reliably in all circumstances in 3.0b. 5.0 is a different story however. 5.0 is better at event
processing (less windows where it cannot handle them), and it takes advantage of a function of OLE controls where it can request of a
control to Freeze Event firing. The RAS Control does not process this request currently, and this is true of a lot of OCX's. This is why you will
read in the VFP 5 documentation about _VFP.AutoYield. You would use this in the following manner to ensure VFP does not miss events
being fired:

_VFP.AutoYield=.F.
=ThisForm.OleControl1.Object.Dial()
DOEVENTS

VFP 5 documentation says you may need to set AutoYield to .F. if ActiveX controls are on your form; this is why.

Now another problem surfaces with VFP that hits you with the RDA RAS Control - events being fired from multi threaded OCX's. Of course
since OCX is 32 bit technology, many OCX's are multithreaded. However, VFP is again the only known container app that cannot handle
events being fired from more than the main thread! This manifests itself in the RAS control by not seeing Connect, DialingStatus, and
ExtendedError events at times (or most of the time; it will see them some times by luck), as these events can come from a second thread
because you have set up for an asynchronous dial (Asynchronous=.T. before Dial). This HAS to be a second thread because control has
already been returned to you immediately, from the Dial function call! Bottom line is for now, don't use Asynchronous=.T. before dial, make it
.F. you will be connected when Dial returns, or you will get an error code back. It keeps your program from doing other things but given the
nature of VFP I am not sure how safe it would be to do anything else in the interim, it may be hard to capture events.

Other news:

DialUp vs. Dial - Our version 1.1 help file indicates that DialUp was added because Dial does not work correctly - this is not true. The
problem was people calling Dial as this:

=ThisForm.OleControl1.Dial()

instead of this:

=ThisForm.OleControl1.Object.Dial()

the term "Object" is needed to indicate this is a method of the OLE Object not the OLEContainer that houses it. Use without Object will work
sometimes depending on whether there is a naming clash or something. Any way if you do it right, Dial works fine, although you cannot see
the Method in the VFP 5 IDE because VFP sees a Dial event and gets confused! OLE specs allow events and methods to have the same
name, VFP can't handle it.

Summary for You

-Dial works fine if not asynchronous and you use AutoYield=.F./DOEVENTS
-Async dial does not work from the perspective of trapping DialingStatus, Connected, and ExtendedError events reliably because VFP 5
does not handle events from multiple threads.
-VFP 3.0b is not reliable for OCX support -- move to 5.0!



Send mail to webmaster@rdaconsultants.com with questions or comments about this web site.
Revised: Tuesday, December 10, 1996 09:59 AM