This OCX control allows our application to communicate with a Cipherlab 
handheld data collection device.

I don't know if anyone else uses the above control but we have a problem 
that we cannot seem to fix.

The control has a DOWNLOADFILE method that allows the contents of a text 
file (containing product information) to be sent to the handheld.

The problem is that when this method is executed and the data is being 
sent to the handheld, the rest of our application (which opens multi 
dialogs in their own thread) stops reacting to windows events, 
effectively freezing it up.

Has anyone come across this, or something similar using other OCX controls?

Are there any possible workarounds for this?

Thanks
Regan

does each thread have an event loop??

Jim


On 09/26/2012 07:12 AM, Regan Cawkwell wrote:
> This OCX control allows our application to communicate with a Cipherlab
> handheld data collection device.
>
> I don't know if anyone else uses the above control but we have a problem
> that we cannot seem to fix.
>
> The control has a DOWNLOADFILE method that allows the contents of a text
> file (containing product information) to be sent to the handheld.
>
> The problem is that when this method is executed and the data is being
> sent to the handheld, the rest of our application (which opens multi
> dialogs in their own thread) stops reacting to windows events,
> effectively freezing it up.
>
> Has anyone come across this, or something similar using other OCX controls?
>
> Are there any possible workarounds for this?
>
> Thanks
> Regan

Yes.  We use Express++ to create our dialogs, etc.

The OCX is loaded when the dialog is created using Rogers 
DCACTIVEXCONTROL clause.

And the DOWNLOADFILE method is activated within a codeblock executed by 
a button on that dialog.

Is it possible that the ActiveX control is written so badly that it does 
not release any time slices back to Windows while it is communicating 
with the handheld device?

On 27/09/2012 00:20, James Loughner wrote:
>
> does each thread have an event loop??
>
> Jim
>
>
> On 09/26/2012 07:12 AM, Regan Cawkwell wrote:
>> This OCX control allows our application to communicate with a Cipherlab
>> handheld data collection device.
>>
>> I don't know if anyone else uses the above control but we have a problem
>> that we cannot seem to fix.
>>
>> The control has a DOWNLOADFILE method that allows the contents of a text
>> file (containing product information) to be sent to the handheld.
>>
>> The problem is that when this method is executed and the data is being
>> sent to the handheld, the rest of our application (which opens multi
>> dialogs in their own thread) stops reacting to windows events,
>> effectively freezing it up.
>>
>> Has anyone come across this, or something similar using other OCX
>> controls?
>>
>> Are there any possible workarounds for this?
>>
>> Thanks
>> Regan
>

hi,

> Is it possible that the ActiveX control is written so badly that it does 
> not release any time slices back to Windows while it is communicating with 
> the handheld device?

why you think OCX works wrong ... show us some Code

to find out what your Problem is i recommend to make a Demo
without Threads. activeX are running in GuiThread so you need
to o:subscribeEvent() to receive Events and react on it.

while you say your Application seem not to "hang" but react "very slow"
it remind me on RTF Problem with RICHTX32.OCX ...
there are some "undocumented" activeX IVar ... ask Alaska

greetings by OHR
Jimmy

On 27/09/2012 22:02, AUGE_ OHR wrote:
> hi,
>
>> Is it possible that the ActiveX control is written so badly that it does
>> not release any time slices back to Windows while it is communicating with
>> the handheld device?
>
> why you think OCX works wrong ... show us some Code

The reason I think that it works wrong is that the OCX control 
documentation does not mention any events that can, or need to, be 
reacted to.

The OCX functions available are:

SetPort()
GetPort()
SetBaudRate()
GetBaudRate()
SetTimeout()
GetTimeout()
InitConnection()
CloseConnection()
ReadFile()
DownloadFile()

and that is it.

Once we call the DownloadFile() function, the lockup occurs.

> to find out what your Problem is i recommend to make a Demo
> without Threads. activeX are running in GuiThread so you need
> to o:subscribeEvent() to receive Events and react on it.

Again, no mention has been made of any events that need to be reacted 
to.  So I wouldn't know what to hook onto.

The idea of making a small sample is sound but would be a little more 
complex for me as I generally only write using Express++.  Although I 
have occasionally dabbled in the raw Xbase++ code I do not generally do 
so and it would take me longer than most...

> while you say your Application seem not to "hang" but react "very slow"
> it remind me on RTF Problem with RICHTX32.OCX ...
> there are some "undocumented" activeX IVar ... ask Alaska

I don't recall saying that it went "very slow".  It just hangs until the 
DownloadFile function has finished sending data to the handheld.

But for what it's worth, I did initially think about those undocumented 
features you are talking about.  I should have mentioned that we did try 
setting them based on messages I found that mentioned them in these 
newsgroups.  They made no difference...but we could have been using them 
wrongly I suppose.

Thanks anyway.
Regan

hi,

> The reason I think that it works wrong is that the OCX control

not every OCX, working with VB, will work with Xbase++

>documentation does not mention any events that can, or need to, be reacted 
>to.

hm ... if you do not have Events to react to than try
CreateObject() or use DispHPR.DLL with ot4xb

>They made no difference...but we could have been using them wrongly I 
>suppose.

show use some Code ...
is there any Link to download a Demo Version ?

greetings by OHR
Jimmy

Hi Jimmy

On 28/09/2012 17:51, AUGE_ OHR wrote:
> hi,
>
>> The reason I think that it works wrong is that the OCX control
>
> not every OCX, working with VB, will work with Xbase++

I know.  I asked if anyone else had used it for just that reason.

>
>> documentation does not mention any events that can, or need to, be reacted
>> to.
>
> hm ... if you do not have Events to react to than try
> CreateObject() or use DispHPR.DLL with ot4xb

I will try using CreateObject() again.  I tried that a while back and 
could not get it to work so I ended up trying Rogers DCACTIVEXCONTROL 
command instead and that worked fine.  I probably just got something 
obviously wrong...

I haven't tried (or even heard of..) DispHPR.DLL along with Pablos 
library.  That might be a possibility if nothing else works.

>
>> They made no difference...but we could have been using them wrongly I
>> suppose.
>
> show use some Code ...
> is there any Link to download a Demo Version ?

The OCX is supplied as part of the Cipherlabs Forge Batch Application 
Generator that in turn is supplied with certain models of the handheld 
in question.  The other problem is that it requires one of their 
handhelds to actually communicate with.

I have put a call into CipherLab themselves to see if there is an 
updated OCX that may fix the problem.  We'll see if they surprise me!

Also, the devcon thing is in two weeks.  I'm not able to go but my 
colleague is.  Maybe I'll get him to ambush the alaska staff to see what 
they make of it if all else fails.

Thanks for the comments and ideas.
Regan