Modal Object
in [Visual Basic]
|
Prev: touchpad programming
Next: Visual Basic.net
From: David on 28 Apr 2010 21:30 Thanks, will kept that in mind "GS" <GS(a)discussions.microsoft.com> wrote in message news:uiODk9y5KHA.980(a)TK2MSFTNGP04.phx.gbl... > Just a suggestion... > > If you're referring to the Dan Appleman associated with Desaware, he's > been pretty good about conversing directly with me concerning issues with > his products/ideas. I think he'd be just as accommodating to you if you > were to contact him yourself to get his opinion about how you've > implemented is concept. > > Kind regards, > Garry > >
From: David on 29 Apr 2010 09:01 Mr. Butler: While using an ActiveX makes sense and would move most of the tool code outside the charting app, where I see the problem is once the mouse events are "being used" (especially mouse move), then the picturebox is in control. At that point, whether the code reside in the parent app or in the ActiveX, should make no difference as both the charting portion and tool portion are trying to use the same picturebox "effectively at the same time". .. The charting portion of the App already uses an ActiveX and timer yet issues still exist. More DoEvents may help, but unless I'm wrong, this would use up more clock ticks making the call to DoEvents than are currently already available. I also don't think muli-threading will help as IMHO this is just smoke and mirrors with one processor. "Bob Butler" <noway(a)nospam.ever> wrote in message news:ORmEvHv5KHA.6052(a)TK2MSFTNGP02.phx.gbl... > > "David" <NoWhere(a)earthlink.net> wrote in message > news:eYFIApu5KHA.3184(a)TK2MSFTNGP05.phx.gbl... >> What I had in mind is this: >> >> I have a set of tools that are used as overlays on charts that are >> updated in real-time. If I use my menu choices (here MDI menu) >> or another form (vbmodal not child) -- no -- impact occurs >> on the real-time chart display. However, if I use the tools which are >> used on the same Picturebox, the real-time chart is impacted >> as it is in the same master loop as charting. >> >> I have attempted to resolve this by buffering the chart data, >> -- wait for an opening (delay) -- send the chart data to the buffer >> then use the tool. When the tool usage is completed, I dump the buffer >> to the chart and continue with real-time. The above was done based on an >> Appleman article I read years ago regarding event conflicts, >> VB, and phasing >> >> While the above works, at times users complain because of the delay >> either in the tools or the chart. >> >> Logic says if I could make the tools modal (like the menus) . However, >> the big kicker is that both the charting and tools may be drawing to the >> same bitmap (picturebox) at the same time. > > I'm still not exactly clear on what you are describing but I think you are > trying to get to multi-threading which is not simple in VB. It has > nothing to do with anything being "modal". > > I'm assuming that the real-time chart display is reacting to some external > event that causes part or all of the chart to be updated. If you call a > procedure in your "tool" that does a lot of calculations and drawing but > does not yield time for the chart events to occur then they will pend > until the tool finishes. It might be as simple as adding DoEvents inside > the tool to let the chart catch up. You might also need to look at > threading, which is possible in VB but requires care, or using an ActiveX > Exe for the tool to isolate those calculations and let it raise events > back to update the charts. >
From: Jeff Johnson on 4 May 2010 14:38 "David" <NoWhere(a)earthlink.net> wrote in message news:%23jquLw55KHA.5848(a)TK2MSFTNGP06.phx.gbl... > I also don't think muli-threading will help as IMHO this is just smoke and > mirrors with one processor. Multi-threading IS smoke and mirrors with one processor. Once you move to multiple processors you usually start to call it "parallel processing" and not multi-threading (although multiple threads are involved).
From: Helmut Meukel on 4 May 2010 16:02
"David" <NoWhere(a)earthlink.net> schrieb im Newsbeitrag news:%23jquLw55KHA.5848(a)TK2MSFTNGP06.phx.gbl... > > I also don't think muli-threading will help as IMHO this is just smoke and > mirrors with one processor. > So is multi-tasking. Would you like to go back to single-tasking DOS? CPU time is split between different tasks, to get more things done "simultaneously", not one after another. Multi-threading is basically the same thing just applied to tasks within a program. I think your app is the perfect candidate for multi-threading. BTW, isn't using a state machine a crude way to implement a fake multi-threading? Just my 2 cents. Helmut. |