Re: ActiveX.exe more problems


"Schmidt" <sss@xxxxxxxxx> wrote in message
news:uGi7zmohGHA.1276@xxxxxxxxxxxxxxxxxxxxxxx

"Galen Somerville" <galen@xxxxxxxxxxxx> schrieb im Newsbeitrag
news:em0EminhGHA.2364@xxxxxxxxxxxxxxxxxxxxxxx

I hear you but my thinking goes this way...
I hear you too ;-), but that's not, how it should be done IMO.

I think about your USB-Device as a "Streaming-Device", wich
samples your incoming data continously (more or less, there
are probably some FIFOs involved).

And that's my problem, it's not a Streaming device. Jungo assumes this too
and their new drivers for NET are basically made that way. That's why I'm
going to use a VB6 dll as I can then use Jungo as "send commands" and "get
replies".

Probably 98% of USB devices stream data from a hard drive, scanner, etc.
Mine doesn't.

So, as long as you want to visualize continously, keep the Thread
(wich recieves these continous data from your device) alive.
No need, to kill the thread after receiving a single "line of data".
As long as you want to continously visualize inside your Application,
as long lives and captures the thread your USB-Data.

Both the App and the USB device know exactly what is
happening.
Not exactly sure, what you mean with this.

Both the App and the USB device automatically stop processing after 1,020
pixels of data. No communications between them saying they are done. If the
App doesn't see an Abort or Stop flag it starts interrogating the USB device
until it sees that the Trigger level has been reached. Then the whole 1,020
pixel operation starts over again.


So in MainLoop would be this:

For Index = 0 To Count - 1
As said, no need to limit the Threads LiveTime to a single line of data.


It's not a single line of data. The thread will be alive for 170 transfers
of 24 byte packets. Each packet will raise an event so the App can draw
partial traces while the next packet is being received. Packets are received
every 14 ms typically. This depends on the Heart rate and number of beats
displayed. Could be shorter or much longer intervals.

Stat = WDU_TransferInterrupt(Dev, 129, True, 0, VarPtr(DatAry(0)),
Quant, Xsfrd, Twait)
Ok, but better with DatAry(s), sitting in Ringbuffer-Slots ;-)

If Stat <> STATUS_SUCCESS Then
sMsg2 = Stat2Str(Stat)
End If
better (enhance the SharedData-Type appropriately):
If Stat <> STATUS_SUCCESS Then
SharedArr(0).StatErrNr = Stat
Goto ex 'let's exit the DeviceLoop
End If

RaiseEvent CheckBuffer
No, no way, really - this is exactly the point, that brings all
the trouble into the game (CrossThread-Event-Marshaling
with all those potential blocking-issues)


The raised event "CheckBuffer" is just a rename of the
"CheckRingBufferQueue"
Raising the event was just moved from the Form to the Class

And in Cmain would be this:

Private Sub CallbackForm_CheckBuffer()
RaiseEvent BurstEvent(DatAry)
End Sub
No, this type of Event-Cascading between the Threads is
simply not the way to go, if a stable capturing is your goal.
Definitely go with the RingBuffer - it is visible to both threads
at the same time. Inside CMain, wich runs on the same thread
as the whole App, you only have to check, where the last
RingBuffer-Index points to - the data is already filled in at
that point by CThread.

If the DatAry was Public in the bas module isn't it visible to both threads
just like the ring buffer?

Feel free to ask about the whole construct, if you not fully
understand, how it works with all those Modulo-Operations
on the Indices.
Sometimes I have to use my fingers, if I have to deal with
such stuff (and proof offsets and shiftings) myself.

I think I'm also using my toes. (g)


Public Event BurstEvent(DatAry() As Byte)
Ok, as recommended.

Olaf


Galen


.

Relevant Pages

  • Re: Firing Events from Modile containing a Threads code
    ... > Ive been advised to use events in my app. ... listens for UDP packets. ... hence the event gets fired twice, ... first procedure to finish executing and then call the method again in ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Weird (unsecure?) behaviour when trying IP forwarding.
    ... MAC address set to my PDAs mac, but the destination IP address is not ... one of the PDA. ... somehow the packets are always accepted, but then why is this and what ... Don't laugh with the last thing, at one moment we had an app running on ...
    (microsoft.public.pocketpc.developer.networking)
  • Re: IOCP critical sections and mutexes
    ... just deleted object. ... My packets never go over 2k in size. ... then pushes it in a queue that will be later processed by my main app ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
  • Weird (unsecure?) behaviour when trying IP forwarding.
    ... MAC address set to my PDAs mac, but the destination IP address is not ... one of the PDA. ... somehow the packets are always accepted, but then why is this and what ... Don't laugh with the last thing, at one moment we had an app running on ...
    (microsoft.public.pocketpc.developer.networking)