ActiveX Questions - Expert Needed

**Steve Gerrard** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

"dw85745" <dw85745@gbronl ine.com> wrote in message
news:YuadnQHJ35 dP026iRVn-gQ@gbronline.co m...[color=blue]
> PROBLEMS I Haven't solved:
>
> When the user selects a tool and drags it across the screen to
> position, the mouse_move event is in
> control. If server#1 raises an event to draw on the real time
> graphics a conflict arises.[/color]

I don't understand what you mean by "in control". You should be
responding to a whole series of mouse_move events during a drag. Other
events, such as those raised by your server, should be able to fire in
between the mouse_move events. What do you mean by "a conflict arises"?

**dw85745** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

Thanks for responding Steve:

1) I'm the client app.
2) I have an MDI.
3) On the MDI are child forms which contain picture boxes
------ To make it simple just think of one form with a picturebox
taking up the entire client area.

4) A picturebox (control) is used for all drawing.
5) The mouse move event (which uses my drawing tool functions to draw on
the picture box) is an event
associated with the picture box (control.)
6) The real time drawing is drawn in the same picture box (control) when
the component event (on a hidden
form which link to server #1) is triggered and calls my drawing
functions.

Hope this makes it clearer.

David

"Steve Gerrard" <notstevegerrar d@comcast.net> wrote in message
news:K4udnU571Z fF-G6iRVn-uA@comcast.com. ..[color=blue]
>
> "dw85745" <dw85745@gbronl ine.com> wrote in message
> news:YuadnQHJ35 dP026iRVn-gQ@gbronline.co m...[color=green]
> > PROBLEMS I Haven't solved:
> >
> > When the user selects a tool and drags it across the screen to
> > position, the mouse_move event is in
> > control. If server#1 raises an event to draw on the real time
> > graphics a conflict arises.[/color]
>
> I don't understand what you mean by "in control". You should be
> responding to a whole series of mouse_move events during a drag. Other
> events, such as those raised by your server, should be able to fire in
> between the mouse_move events. What do you mean by "a conflict arises"?
>
>[/color]

**Steve Gerrard** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

"dw85745" <dw85745@gbronl ine.com> wrote in message
news:lOednRbnL9 Sg8W6iRVn-hg@gbronline.co m...[color=blue]
>
> 5) The mouse move event (which uses my drawing tool functions to draw[/color]
on[color=blue]
> the picture box) is an event
> associated with the picture box (control.)[/color]
[color=blue]
> 6) The real time drawing is drawn in the same picture box (control)[/color]
when[color=blue]
> the component event (on a hidden
> form which link to server #1) is triggered and calls my drawing
> functions.
>[/color]

There is no reason that I can see that these two events can't be mingled
together on your form. What is the conflict? The mouse move event
handler should not be taking long to run, or the user would see jumpy
behavior. It should be doing small updates to the picture box each time
it is called. After each mouse move event is handled, any other events
will be processed, including the event raised by your component.

Are you by any chance using one of the Drag modes (DragOver or
OleDragOver)?

**dw85745** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

Thanks for responding Steve:

------------
Are you by any chance using one of the Drag modes (DragOver or[color=blue]
> OleDragOver)?[/color]
------------
No, Everything is done from drawing functions using XOR or Invert.
Further everything is painted instead of BitBlt for speed and memory
requirements.

-------------
There is no reason that I can see that these two events can't be mingled[color=blue]
> together on your form. What is the conflict?[/color]
-------------

It's a display issue. When dragging (say a horizontal line) up and down
while holding the
left mouse button, and the real-time routine triggers, then the erase side
of XOR seems to
quit working and I get multiple lines instead of just one.

Currently have drawing routines in a module for quick development, but
thought I'd try
moving most of them to a EXE component to see if that helped since a
separate app
solved conflict -- but didn't want to go to all the effort right now, if
feedback is NO solution.

David

"Steve Gerrard" <notstevegerrar d@comcast.net> wrote in message
news:uKydnS7GWL PNFGmiRVn-ug@comcast.com. ..[color=blue]
>
> "dw85745" <dw85745@gbronl ine.com> wrote in message
> news:lOednRbnL9 Sg8W6iRVn-hg@gbronline.co m...[color=green]
> >
> > 5) The mouse move event (which uses my drawing tool functions to draw[/color]
> on[color=green]
> > the picture box) is an event
> > associated with the picture box (control.)[/color]
>[color=green]
> > 6) The real time drawing is drawn in the same picture box (control)[/color]
> when[color=green]
> > the component event (on a hidden
> > form which link to server #1) is triggered and calls my drawing
> > functions.
> >[/color]
>
> There is no reason that I can see that these two events can't be mingled
> together on your form. What is the conflict? The mouse move event
> handler should not be taking long to run, or the user would see jumpy
> behavior. It should be doing small updates to the picture box each time
> it is called. After each mouse move event is handled, any other events
> will be processed, including the event raised by your component.
>
> Are you by any chance using one of the Drag modes (DragOver or
> OleDragOver)?
>
>
>[/color]

**Steve Gerrard** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

"dw85745" <dw85745@gbronl ine.com> wrote in message
news:Pv6dnZ4vd7 3LwWiiRVn-gg@gbronline.co m...[color=blue]
> No, Everything is done from drawing functions using XOR or Invert.
> Further everything is painted instead of BitBlt for speed and memory
> requirements.
>
> It's a display issue. When dragging (say a horizontal line) up and[/color]
down[color=blue]
> while holding the
> left mouse button, and the real-time routine triggers, then the erase[/color]
side[color=blue]
> of XOR seems to
> quit working and I get multiple lines instead of just one.
>[/color]

Okay, that sounds more like the problem. It doesn't seem like an event
related thing, its more of a graphics issue. I can see how an XOR
operation might get mangled if some other drawing activity took place
between the erase and the redraw.
[color=blue]
> Currently have drawing routines in a module for quick development, but
> thought I'd try
> moving most of them to a EXE component to see if that helped since a
> separate app
> solved conflict -- but didn't want to go to all the effort right now,[/color]
if[color=blue]
> feedback is NO solution.
>[/color]

It doesn't seem to me to be a threading issue, which is really what
making separate exe components addresses. You still wind up with one
window to draw on, and one thread to do the drawing. Even in VB.Net, the
actual GUI updating is supposed to all take place in the same thread. I
think you would always get weird problems like the "drawing underneath"
one you mentioned.

I would first exhaust the possibilities of using the Refresh command on
the picure box, and toggling the AutoRedraw property on and off, and
anything else you can think of, to see if there was anyway to get it to
behave properly.

Is it really essential to update the display with the real time data
while a user is dragging a horizontal line? Maybe you could store some
results and update after they release the mouse button, or make a
temporary second picture box for them to drag over, or something.

**dw85745** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

Thanks for responding Steve
[color=blue]
> Is it really essential to update the display with the real time data
> while a user is dragging a horizontal line? Maybe you could store some
> results and update after they release the mouse button, or make a
> temporary second picture box for them to drag over, or something.[/color]

Have thought about making some type of stack to hold the real-time values
until
the user finishes, then pop the stack and do the drawing. Have to give some
thought
to this as have some time issues (my moving up values in arrays is linked to
the
time stamp on the real-time feed) to think about.

Read an article by Dan Appleman about "state machines" some time back
with deals with reentrant code but from my reading appears a real headache
to implement.

Appreciate the discussion on NOT believing its a threading issue as this
helps
clear up some mental blockage.

David

"Steve Gerrard" <notstevegerrar d@comcast.net> wrote in message
news:qb2dnfNn_r 4-K2iiRVn-jA@comcast.com. ..[color=blue]
>
> "dw85745" <dw85745@gbronl ine.com> wrote in message
> news:Pv6dnZ4vd7 3LwWiiRVn-gg@gbronline.co m...[color=green]
> > No, Everything is done from drawing functions using XOR or Invert.
> > Further everything is painted instead of BitBlt for speed and memory
> > requirements.
> >
> > It's a display issue. When dragging (say a horizontal line) up and[/color]
> down[color=green]
> > while holding the
> > left mouse button, and the real-time routine triggers, then the erase[/color]
> side[color=green]
> > of XOR seems to
> > quit working and I get multiple lines instead of just one.
> >[/color]
>
> Okay, that sounds more like the problem. It doesn't seem like an event
> related thing, its more of a graphics issue. I can see how an XOR
> operation might get mangled if some other drawing activity took place
> between the erase and the redraw.
>[color=green]
> > Currently have drawing routines in a module for quick development, but
> > thought I'd try
> > moving most of them to a EXE component to see if that helped since a
> > separate app
> > solved conflict -- but didn't want to go to all the effort right now,[/color]
> if[color=green]
> > feedback is NO solution.
> >[/color]
>
> It doesn't seem to me to be a threading issue, which is really what
> making separate exe components addresses. You still wind up with one
> window to draw on, and one thread to do the drawing. Even in VB.Net, the
> actual GUI updating is supposed to all take place in the same thread. I
> think you would always get weird problems like the "drawing underneath"
> one you mentioned.
>
> I would first exhaust the possibilities of using the Refresh command on
> the picure box, and toggling the AutoRedraw property on and off, and
> anything else you can think of, to see if there was anyway to get it to
> behave properly.
>
> Is it really essential to update the display with the real time data
> while a user is dragging a horizontal line? Maybe you could store some
> results and update after they release the mouse button, or make a
> temporary second picture box for them to drag over, or something.
>
>
>[/color]

**Steve Gerrard** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

"dw85745" <dw85745@gbronl ine.com> wrote in message
news:7pudnRplzq snTmiiRVn-hA@gbronline.co m...[color=blue]
>
> Have thought about making some type of stack to hold the real-time[/color]
values[color=blue]
> until
> the user finishes, then pop the stack and do the drawing. Have to[/color]
give some[color=blue]
> thought
> to this as have some time issues (my moving up values in arrays is[/color]
linked to[color=blue]
> the
> time stamp on the real-time feed) to think about.
>
>[/color]

I think you need to split the process of updating your array with the
real-time data from the actual drawing of it. The array update should
proceed regardless of whether or when it will be drawn. That could be
done in the server.exe, I think.

If the server raises a DataChanged event, then when the app gets around
to processing it, the app can retrieve the latest values of the array by
using a separate function rather than something passed with the event.
If it were points in a line, for instance, the app could get the point
array from the server, then call some Polyline API or whatever to draw
it.

I know you would like to get the actual drawing code into the server as
well, but it is probably not a good idea. Windows will be much happier
if the main app thread does the actual drawing. Your server could do
everything else to prepare the data for drawing, such as scaling, etc.

**dw85745** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

Thanks for responding Steve:

Appreciate your feedback and taking the time to help me get this resolved.
I know part (if not most) of this is a design issue I'm trying to correct as
I've climbed the learning curve.

Part of "my indecision" has been whether to move the drawing tools or the
real-time calculation
to a separate thread (tough in VB) or a separate process (exe component).

-------------
The array update should proceed regardless of whether or when it will be
drawn. That could be[color=blue]
> done in the server.exe, I think.[/color]
--------------

I currently use tier down UDT's which contain arrays. A simple example
would be:

Type Child < identifies each child in the MDI
Type DataSet < identifies a dataset
HistDataArrays < (historical)
RTData < (realtime -- the latest value)
Type Chart < Controls all drawing
Type Tools < Controls tools
End Type

The historical data arrays are fixed in size, but are a FIFO buffer -- when
the realtime times outs, it pushes the oldest historical out. This way the
user can see a select amount of historical information (by scrolling) as
well as the real time when NOT scrolling.

The receipt of the real-time data triggers the real-time drawing. When a
timeout occurs (approx. every minute) the historical is redrawn, the
real-time buffer is flushed and real-time starts over.

-------------[color=blue]
> If the server raises a DataChanged event, then[/color]

when the app gets around to processing it
<KEY WORDS
[color=blue]
>, the app can retrieve the latest values of the array by
> using a separate function rather than something passed with the event.[/color]
-------------

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.

David

"Steve Gerrard" <notstevegerrar d@comcast.net> wrote in message
news:Mpqdnf5gUe fQuWuiRVn-vg@comcast.com. ..[color=blue]
>
> "dw85745" <dw85745@gbronl ine.com> wrote in message
> news:7pudnRplzq snTmiiRVn-hA@gbronline.co m...[color=green]
> >
> > Have thought about making some type of stack to hold the real-time[/color]
> values[color=green]
> > until
> > the user finishes, then pop the stack and do the drawing. Have to[/color]
> give some[color=green]
> > thought
> > to this as have some time issues (my moving up values in arrays is[/color]
> linked to[color=green]
> > the
> > time stamp on the real-time feed) to think about.
> >
> >[/color]
>
> I think you need to split the process of updating your array with the
> real-time data from the actual drawing of it. The array update should
> proceed regardless of whether or when it will be drawn. That could be
> done in the server.exe, I think.
>
> If the server raises a DataChanged event, then when the app gets around
> to processing it, the app can retrieve the latest values of the array by
> using a separate function rather than something passed with the event.
> If it were points in a line, for instance, the app could get the point
> array from the server, then call some Polyline API or whatever to draw
> it.
>
> I know you would like to get the actual drawing code into the server as
> well, but it is probably not a good idea. Windows will be much happier
> if the main app thread does the actual drawing. Your server could do
> everything else to prepare the data for drawing, such as scaling, etc.
>
>
>[/color]

**Steve Gerrard** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

"dw85745" <dw85745@gbronl ine.com> wrote in message
news:9OGdnTQpwN zrf2uiRVn-hw@gbronline.co m...[color=blue]
>
> By moving to a separate process(exe) I gain the efficiency of letting[/color]
the[color=blue]
> user/mouse do their thing, while the real-time is updating. (All well[/color]
and[color=blue]
> 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[/color]
need[color=blue]
> be suspended
> until the tools is finished ------- UNLESS at the end of the mousemove[/color]
loop[color=blue]
> 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[/color]
real-time[color=blue]
> TIMEOUT occurs -- if it occurs while the mouse is being used.
>
>[/color]

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_Mous e_Move_Event
Erase dragged item, using XOR
Position at new location
Draw dragged item using XOR

PictureBox_Real Time_Update_Eve nt
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** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

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" <notstevegerrar d@comcast.net> wrote in message
news:7e2dnUA54r 5L7GqiRVn-uA@comcast.com. ..[color=blue]
>
> "dw85745" <dw85745@gbronl ine.com> wrote in message
> news:9OGdnTQpwN zrf2uiRVn-hw@gbronline.co m...[color=green]
> >
> > By moving to a separate process(exe) I gain the efficiency of letting[/color]
> the[color=green]
> > user/mouse do their thing, while the real-time is updating. (All well[/color]
> and[color=green]
> > 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[/color]
> need[color=green]
> > be suspended
> > until the tools is finished ------- UNLESS at the end of the mousemove[/color]
> loop[color=green]
> > 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[/color]
> real-time[color=green]
> > TIMEOUT occurs -- if it occurs while the mouse is being used.
> >
> >[/color]
>
> 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_Mous e_Move_Event
> Erase dragged item, using XOR
> Position at new location
> Draw dragged item using XOR
>
> PictureBox_Real Time_Update_Eve nt
> 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...
>
>[/color]

**Steve Gerrard** · Jul 17 '05, 08:34 PM

Re: ActiveX Questions - Expert Needed

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

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).
[color=blue]
> If your EMAIL address in header is good (????) I'll send you an[/color]
example of[color=blue]
> the 1st XProceess test
> I put together -- if of interest. Will take me a couple days to THINK[/color]
and[color=blue]
> rework a new one.
>[/color]

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.

ActiveX Questions - Expert Needed

ActiveX Questions - Expert Needed

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment