469,352 Members | 1,661 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,352 developers. It's quick & easy.

ActiveX Questions - Expert Needed

PROBLEMS I Haven't solved:

1. Timing issue between real-time server #1 and my drawing tools.
Will moving the tools
(currently within module) to an ActiveX (exe or DLL) solve the
problem or will the calls to
the ActiveX in the mouse move event still result in a conflict????

Background

Tools are implemented on a toolbar on an MDI form. A component on
a hidden form
generates events when real-time data is received and these events
are used to draw graphics in the
same picturebox that the tools are used.

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. I tried
implementing the tools in a separate process and this eliminated
the conflict but the
tool drawing shows up UNDER the real-time graphics instead of
ontop. Because of the x-process call
there is no way to control when the timing of the drawing will
occur in relation to the real-time graphics.

I've thinking about moving the drawing tools functions/subs to an
ActiveX to see of this would help solve
the conflict. I have some popup windows which allow each tool to
be configured, but from my
understanding it is suggested an ActiveX NOT support independent
forms. These forms could remain
in the MDI as all they would do is set the default property of each
drawing tool, but if they could be
included in the ActiveX it would make for a nice clean
consolidation.

Whether the OS will give enough time for using the mouse at the
same time
the real time graphics may be processing(set and drawing) is
unknown to me???????????

2. Can a separate application which links to server #2 be contained
within an ActiveX and then included
within an MDI form for usage????

Background

The separate app contains a component which links to server #2 and
has one main form that requires the
user to interface with it as needed??????

Thanks

David

Jul 17 '05 #1
11 2742

"dw85745" <dw*****@gbronline.com> wrote in message
news:Yu********************@gbronline.com...
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.


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"?
Jul 17 '05 #2
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" <no*************@comcast.net> wrote in message
news:K4********************@comcast.com...

"dw85745" <dw*****@gbronline.com> wrote in message
news:Yu********************@gbronline.com...
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.


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"?

Jul 17 '05 #3

"dw85745" <dw*****@gbronline.com> wrote in message
news:lO********************@gbronline.com...

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.


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)?

Jul 17 '05 #4
Thanks for responding Steve:

------------
Are you by any chance using one of the Drag modes (DragOver or
OleDragOver)? ------------
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 together on your form. What is the conflict? -------------

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" <no*************@comcast.net> wrote in message
news:uK********************@comcast.com...
"dw85745" <dw*****@gbronline.com> wrote in message
news:lO********************@gbronline.com...

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.


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)?

Jul 17 '05 #5

"dw85745" <dw*****@gbronline.com> wrote in message
news:Pv********************@gbronline.com...
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 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.

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.
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.


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.

Jul 17 '05 #6
Thanks for responding Steve
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.
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" <no*************@comcast.net> wrote in message
news:qb********************@comcast.com...
"dw85745" <dw*****@gbronline.com> wrote in message
news:Pv********************@gbronline.com...
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

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.


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.
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.


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.

Jul 17 '05 #7

"dw85745" <dw*****@gbronline.com> wrote in message
news:7p********************@gbronline.com...

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.


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.

Jul 17 '05 #8
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
done in the server.exe, I think. --------------

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.

------------- If the server raises a DataChanged event, then
when the app gets around to processing it
<KEY WORDS
, the app can retrieve the latest values of the array by
using a separate function rather than something passed with the event. -------------

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" <no*************@comcast.net> wrote in message
news:Mp********************@comcast.com...
"dw85745" <dw*****@gbronline.com> wrote in message
news:7p********************@gbronline.com...

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.


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.

Jul 17 '05 #9

"dw85745" <dw*****@gbronline.com> wrote in message
news:9O********************@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...
Jul 17 '05 #10
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" <no*************@comcast.net> wrote in message
news:7e********************@comcast.com...

"dw85745" <dw*****@gbronline.com> wrote in message
news:9O********************@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...

Jul 17 '05 #11

"dw85745" <dw*****@gbronline.com> wrote in message
news:yb********************@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.
Jul 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Andrew | last post: by
2 posts views Thread by Matthew Hood | last post: by
1 post views Thread by fniles | last post: by
40 posts views Thread by aarklon | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.