Re: ActiveX.exe more problems

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Schmidt" <sss@xxxxxxxxx> wrote in message
news:ezmiZcrhGHA.3584@xxxxxxxxxxxxxxxxxxxxxxx

"Galen Somerville" <galen@xxxxxxxxxxxx> schrieb im Newsbeitrag
news:ueP84uqhGHA.4504@xxxxxxxxxxxxxxxxxxxxxxx

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.

Independently if we define continous Data-Sampling using the Device-
API-Calls as streaming or not - it is not necessary, to shutdown and
restart the Device-Thread every 2.5 seconds.
If you really must have those interruptions after each completed scanline
(1020 pixels), then let the thread simply in its loop, until you set a
flag
over the shared-array, to signalize the next round of sampling.


Got it. Once the Device-Thread is started it will remain running until the
App sees an Abort or Stop flag.
After each 1,020 pixels a shared-array flag will be set. This flag will be
cleared after a new trigger level has been found.

I will put everything back the way you had it and make the changes that you
described.

It's not a single line of data. The thread will be alive for 170
transfers
of 24 byte packets.
I meant a (screen-) scanline - and the thread should be alive, as long as
the MainApplication is alive and the USB-Device is connected to the PC.
As said above - there's absolutely no problem, to signalize from CThread
to CMain (using the shared-array), that the scanline is completed and it
is also no problem for CMain, to tell CThread (wich is looping all the
time)
that it has to begin data-sampling again for the next scanline (again
using
the shared array with another additional flag).

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.
You will have no problems with this using the demo-approach.

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
But the Form is instantiated inside CMain, receiving PostMessage-
Calls from CThread. The demo-code is a robust construct, as
long as you don't change the principle, how it works.
The usage of VBs RaiseEvent is tabu from inside CThread.
All what CThread has to do is:
Loop,
check for Command-Flags in the SharedArray (from CMain),
retreive new data from the device and store it in the next slot
PostMessage to CMain, to trigger the Callback-Event
Loop again
Nothing more, it is that simple.

All what CMain has to do is:
offer a userinterface to the Main-App, that hides the dirty
details of the device-handling (those are inside CThread)
StartDevice, CloseDevice (evtl. StartNewScanline)
and the Event wich transports the datasamples to the
MainApp + evtl. an Event "ScanLineReady".
Three Public Methods and two Events, simple.
Now the more complex part of CMain.
The PostMessage-Call from CThread is received in the
HelperForms KeyDown-Event. From there it is directed
to CMains CheckRingBufferQueue.
Inside this procedure, the shared-array is checked ("from the
other side"), up to the newest slot with the newest DatAry-Chunk.
From here you can safely do a RaiseEvent, beaming your
Data into the MainApp.

If the DatAry was Public in the bas module isn't it visible
to both threads just like the ring buffer?
No - only if it is defined inside the SharedArray as a RingBuffer-
Slot.
I've already posted you Code, how to implement the whole thing
using your DatAry inside the Ringbuffer-Slots - just try it this way.


Olaf


Thanks

Galen


.

Relevant Pages

  • Re: ActiveX.exe more problems
    ... , then let the thread simply in its loop, until you set a flag ... over the shared-array, to signalize the next round of sampling. ... As said above - there's absolutely no problem, to signalize from CThread ... is also no problem for CMain, to tell CThread ...
    (microsoft.public.vb.general.discussion)
  • Re: Creating Images in php
    ... A user inputs his/her first and last name and selects which country ... last name and an image of the selected country's flag ... are combined into one image of size x pixels wide by y pixels in ... For instance, imagecreate will create an image, imagechar will write a string to the image, etc. ...
    (comp.lang.php)
  • Re: finding color of bits
    ... the black pixels, and the 0 bits represent the white ... carry flag and so a different method needs to be found. ... result is only 1 if the same bit in both operands is also 1. ... c is used to test each bit of octet in left-to-right order. ...
    (comp.lang.c)
  • Re: MacBook S-Video resolution
    ... Interlaced telly has the same number of pixels for 16:9 and 3:4. ... stream to tell the display how much to flatten the poor little things. ... If you have 16:9 material without the flag, you have to convince the TV ... Stone Age stuff really. ...
    (uk.comp.sys.mac)