Prev: Pesky "Ne active mixer devices available" - Still no fix
Next: mcirosoft word 2000 section breaks
From: Gregory A. Beamer on 28 Dec 2009 11:30
Big Mike <mikeoxbig_1974(a)hotmail.com> wrote in news:2d1ba030-6ce9-4c07-
8d5e-2093740be03b(a)x15g2000vbr.googlegroups.com:

> I've tried to keep the engine (model) separate from the GUI (view) and
> have mostly achieved that. I have only one windows 'form'- i swap out
> different form::panels which represent a different view into the
> engine. some of the panels have a thread which keeps polling the
> engine for changes and uses a delegate posted to the GUIs thread to
> caused a screen refresh.

Is the polling absolutely necessary, or can you move so the Engine fires
events when there are changes and then have them handled only if certain
panels are visible. The event model often works better when you are
dealing with separation of GUI and application logic (engine), as the
GUI responds to changes rather than keeps open threads to determine if
changes have occurred. It is not always possible, I would imagine, but
it is cleaner as the UI determines whether it needs to handle events or
ignore, keeping a cleaner "separation of concerns".

If you have "too many changes", this can burn a lot of perf, but I doubt
you are burning any more than keeping threads alive.

> Why aren't there any references to my app in the call stack?

I am not sure, but more than likely the separate thread is the problem
child, which would not be caught in the callstack of the main thread. I
am not sure how the threads are interacting, but my first guess on why
you are not seeing the call to the app is it is in the callstack of the
polling thread, while the exception is in the primary thread.

In short, it could be the polling thread is locking the listview and the
primary thread is attempting something else.

There are native methods for walking a call stack of additional threads.
I am not sure, off hand, how this is implemented in .NET, however. And
if I found a solution on this box, it would be .NET 2.0+. My other box
is Visual Studio 2010, so it is fully in the 4.0 framework. The solution
might or might not be similar to .NET 1.1 (Visual Studio 2003).

> Why does an action on a button cause a crash an undefined amount of
> time later?
>
> Are there any clues in the callstack that someone can spot?

Based on description, the polling operation is the most likely culprit.
The thread is trying to update. Looking at the call stack, the problem
occurs when copying to a "node" that does not exist at the time. If this
were Visual Studio 2008, you could downloa the PDBs for the .NET
framework and step through what was happening in the debugger and see
use the call stack to move back and forth through the code. But you will
have to capture the other thread's callstack to see the app call, if
what I think is happening is in fact happening.

I am a bit blind here, as I do not have the code base (and I am not
asking you to post it here). Hopefully the ideas I have presented are
helping narrow down the exception or giving some ideas of another way to
set up the application that eliminates the problem.

Peace and Grace,


--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 | 
Pages: 1
Prev: Pesky "Ne active mixer devices available" - Still no fix
Next: mcirosoft word 2000 section breaks