Re: ActiveX Questions - Expert Needed - basic.visual

Hi Steve:

Thanks for all your time, efforts and feedback.

Prior to this (your) post, I make two boolean variables based on your
previous comment re
"may be a display issue". One for mousemove and one for the RT drawing
(not calculations).
When the RT drawing routine is called, and the mouse is active, I skipped
the RT drawing
and flagged it to occur at the end of the mousemove event. This way both
the line and xor (erase)
would be completed when chart was called. The same problem arose.

From this, and this post (yours below), I'm in agreement with you that we
need to move all
RT drawing calculations out to an exe as I think it is BOTH a timing issue
(not enough clock ticks
when mouse used) and most probably a display issue.

Based on my previous XProcess sample test (I believe mentioned in my 1st
post), since no conflict
occurred while moving mouise and just a display problem (tool under RT
drawing) , I THINK your below
solution should work. NOW to make a new test.

If your EMAIL address in header is good (????) I'll send you an example of
the 1st XProceess test
I put together -- if of interest. Will take me a couple days to THINK and
rework a new one.

David

"Steve Gerrard" <notstevegerrard@comcast.net> wrote in message
news:7e2dnUA54r5L7GqiRVn-uA@comcast.com...
>
> "dw85745" <dw85745@gbronline.com> wrote in message
> news:9OGdnTQpwNzrf2uiRVn-hw@gbronline.com...
> >
> > By moving to a separate process(exe) I gain the efficiency of letting
> the
> > user/mouse do their thing, while the real-time is updating. (All well
> and
> > good if I can come up with a good redesign). Maybe an array
> > to buffer the real-time data and then using memory mapped files for
> > xprocess.
> >
> > If I went this way, My GUESS is(???), that the real-time drawing would
> need
> > be suspended
> > until the tools is finished ------- UNLESS at the end of the mousemove
> loop
> > I would have enough time
> > grab the real-time data and graph it without causing the tool to be
> > slow/hang.
> >
> > Where my BIG concern is -- is how to handle the data when the
> real-time
> > TIMEOUT occurs -- if it occurs while the mouse is being used.
> >
> >
>
> First, just to warn you, I don't think I can absorb all the details
> without spending more time and looking at more code, so take my comments
> as being off the top of my head (where there used to be more hair...)
>
> It makes sense to me to have the real time stuff in its separate exe and
> thread, raising an event to your app as the data changes. You may only
> want to realize that your app will not always redraw it right away, so
> it should be getting the latest available data whenever it does draw.
>
> A thought occurred to me about the dragged-item redraw, which might fix
> some of the draw/erase issue: The real time draw procedure should also
> erase and redraw the item being dragged by the user. (I think this is
> kind of the opposite of what you said about redrawing the real time data
> in each mouse move event).
>
> Here is what I mean in rough outline:
>
> PictureBox_Mouse_Move_Event
> Erase dragged item, using XOR
> Position at new location
> Draw dragged item using XOR
>
> PictureBox_RealTime_Update_Event
> Erase dragged item, using XOR
> Draw new data in picture box
> Draw dragged item using XOR (at same place)
>
> I think what was happening is that the XOR to erase the dragged item
> wasn't working correctly if the underlying area had been redrawn in the
> mean time by the real time event. By also erasing and redrawing the
> dragged item in the realtime update, you eliminate that problem. It
> might cause some flicker, but it might otherwise fix it. This would
> obviously require some code and variables to keep track of whether
> something was being dragged, and if so, what kind of item it was and
> where it was located, but that should be reasonable to do.
>
> It does sound like an interesting application you have...
>
>

"dw85745" <dw85745@gbronline.com> wrote in message
news:yb2dnULPoYwvvmWiRVn-ig@gbronline.com...
> When the RT drawing routine is called, and the mouse is active, I
skipped
> the RT drawing
> and flagged it to occur at the end of the mousemove event. This way
both
> the line and xor (erase)
> would be completed when chart was called. The same problem arose.

The thing is, you need to erase the old line at the beginning of the
mouse move event. Your code will assume that the old line is unchanged,
but in fact the RT drawing may have changed it in the mean time, so a
ghost gets left behind. That is why the RT code needs to erase the line,
then update, then redraw the line (or other object).

> If your EMAIL address in header is good (????) I'll send you an
example of
> the 1st XProceess test
> I put together -- if of interest. Will take me a couple days to THINK
and
> rework a new one.
>

My real email does not have "not" at the beginning. I do have an
interest, although time is a different question, since the holiday
season is now ending. So, take some time, mull it over, try some things,
and send something if you like.