Author Topic: BackgroundWorker & ShowModalDialog  (Read 17249 times)

0 Members and 1 Guest are viewing this topic.

MikeTuersley

  • Guest
Re: BackgroundWorker & ShowModalDialog
« Reply #30 on: March 09, 2009, 12:59:20 PM »
Well, I said it wasn't pretty but it does work. If the user tries to pick inside cad, they're just picking on the image. It all depends upon how badly and quickly the functionality is needed [try working for a VAR that can only sell fixed bid projects :)]. I'm sure there is a more eloquent and proper workaround.
« Last Edit: March 09, 2009, 02:10:12 PM by MikeTuersley »

Bobby C. Jones

  • Swamp Rat
  • Posts: 516
  • Cry havoc and let loose the dogs of war.
Re: BackgroundWorker & ShowModalDialog
« Reply #31 on: March 10, 2009, 09:09:35 AM »
Hey Mike.  It's good to hear from you.  I missed you at AU this year, although I did run into some of your old co-workers from that VAR :)  Thanks for the suggestions, and welcome to The Swamp.

After some further reading on the net, I think I'm on the right track by checking .InvokeRequired and calling .Invoke, or .BeginInvoke, as needed in the RunWorkerCompleted callback.  Although I am on the hunt for a good book on Windows threading; it was a bad assumption gleaned from an internet site on the BackgroundWorker component, coupled with my ignorance, that lead me to create this bug in the first place.

Well, I said it wasn't pretty but it does work. If the user tries to pick inside cad, they're just picking on the image. It all depends upon how badly and quickly the functionality is needed [try working for a VAR that can only sell fixed bid projects :)]. I'm sure there is a more eloquent and proper workaround.
« Last Edit: March 10, 2009, 10:58:12 AM by Bobby C. Jones »
Bobby C. Jones

MikeTuersley

  • Guest
Re: BackgroundWorker & ShowModalDialog
« Reply #32 on: March 10, 2009, 10:21:31 AM »
Hey Bobby! Nice to "see" you, too! I kept running into people @ AU telling me you were there but I never seemed to be able to track you down. Maybe this year  ;-)

TonyT

  • Guest
Re: BackgroundWorker & ShowModalDialog
« Reply #33 on: March 11, 2009, 05:27:49 PM »
Sorry, have to disagree.

It may work from your perspective if you hold a
myopic view of the problem, and perhaps because
you haven't even begun to consider how easily it
can be broken or how many things can go wrong.

So perhaps in your mind it works.

Realistlcally, it does not.


Well, I said it wasn't pretty but it does work. If the user tries to pick inside cad, they're just picking on the image. It all depends upon how badly and quickly the functionality is needed [try working for a VAR that can only sell fixed bid projects :)]. I'm sure there is a more eloquent and proper workaround.

MikeTuersley

  • Guest
Re: BackgroundWorker & ShowModalDialog
« Reply #34 on: March 11, 2009, 11:35:29 PM »
I totally agree with you - anyone curious could/would get passed it. But, it does remain the only workaround posted good, bad or ugly. I've half expected you to post something using p/invoke, or similar, since you're good at navigating the back doors into the API.

TonyT

  • Guest
Re: BackgroundWorker & ShowModalDialog
« Reply #35 on: March 13, 2009, 05:44:49 AM »
The workaround in this case, is simply to not to use a seperate
background thread.

I don't think it's a good idea to simply blow the user away
by switching to a newly opened document while they may
be in the middle of doing just about anything (like dragging
objects around, or perhaps have another dialog box open,
or what have you).

Do you?

I totally agree with you - anyone curious could/would get passed it. But, it does remain the only workaround posted good, bad or ugly. I've half expected you to post something using p/invoke, or similar, since you're good at navigating the back doors into the API.

MikeTuersley

  • Guest
Re: BackgroundWorker & ShowModalDialog
« Reply #36 on: March 13, 2009, 11:27:07 PM »
LOL Tony! I finally figured out where you are coming from - we are talking apples & oranges

Quote
I don't think it's a good idea to simply blow the user away by switching to a newly opened document while they may be in the middle of doing just about anything (like dragging objects around, or perhaps have another dialog box open, or what have you).

In this instance, I agree.

This is not what I was reading into Bobby's original post. Having some type of background threading is a necessity if you are dealing with backend data sources. I read into Bobby's post that he wanted a long process to run then open a file and use a thread so the user could cancel the operation - MY 'BAD' there because I read more into it. For example, the user selects a new file to open. I override the open and submit the associated xrecord data back to the ERP system then open the requested document. While this is happening, there is a form [as I suggested] displayed that is showing some type of progress indicator and a button to cancel the operation [in case it's running too long or whatever].

Bobby C. Jones

  • Swamp Rat
  • Posts: 516
  • Cry havoc and let loose the dogs of war.
Re: BackgroundWorker & ShowModalDialog
« Reply #37 on: March 16, 2009, 09:07:01 AM »
That's the end goal, to process a request that, when is firing on all cylinders, takes 3 - 5 seconds and then opens the drawing.  There are times, however, that it could take much longer, and I need to give the user feedback on progress as well as provide an option to cancel the request altogether.  I certainly have no desire to blow the user away, well, at least not most of them :-)

Quote
I don't think it's a good idea to simply blow the user away by switching to a newly opened document while they may be in the middle of doing just about anything (like dragging objects around, or perhaps have another dialog box open, or what have you).

In this instance, I agree.

This is not what I was reading into Bobby's original post. Having some type of background threading is a necessity if you are dealing with backend data sources. I read into Bobby's post that he wanted a long process to run then open a file and use a thread so the user could cancel the operation ...].
Bobby C. Jones

TonyT

  • Guest
Re: BackgroundWorker & ShowModalDialog
« Reply #38 on: March 20, 2009, 09:11:48 PM »
Showing a progress UI with the option to cancel doesn't require
a seperate thread, and usually doesn't use one unless you want
to get fancy with AVI animations like Windows file copy.

If the operation involves some kind of loop or the 'atomic' operation
exposes some kind of event that's fired routinely during the process,
then the UI can be updated from the loop or event handler.

That's quite commonly how it's done, because in the overhwelming
number of cases I've seen, progress UIs are blocking (e.g., the user
must either wait or cancel, but can't do anything else).

OTOH if this is more an 'adventure in programming' or threading for
threading's sake, then that's another matter, but the fact remains
the the problem is easily solvable without threading.


That's the end goal, to process a request that, when is firing on all cylinders, takes 3 - 5 seconds and then opens the drawing.  There are times, however, that it could take much longer, and I need to give the user feedback on progress as well as provide an option to cancel the request altogether.  I certainly have no desire to blow the user away, well, at least not most of them :-)

Quote
I don't think it's a good idea to simply blow the user away by switching to a newly opened document while they may be in the middle of doing just about anything (like dragging objects around, or perhaps have another dialog box open, or what have you).

In this instance, I agree.

This is not what I was reading into Bobby's original post. Having some type of background threading is a necessity if you are dealing with backend data sources. I read into Bobby's post that he wanted a long process to run then open a file and use a thread so the user could cancel the operation ...].
« Last Edit: March 20, 2009, 09:58:55 PM by TonyT »

Bobby C. Jones

  • Swamp Rat
  • Posts: 516
  • Cry havoc and let loose the dogs of war.
Re: BackgroundWorker & ShowModalDialog
« Reply #39 on: March 23, 2009, 08:39:13 AM »
Originally this was a single threaded operation that did block the UI while reporting progress.  However, I could not think of a way other than threading to allow canceling.  The operation sends a request to a URL, processes the response, and acts accordingly.  I want to allow the user the ability to cancel while waiting for the response.

This isn't a critical application and I am using it as an opportunity to learn something new.  And that I have; mostly that I don't know jack.

Showing a progress UI with the option to cancel doesn't require
a seperate thread, and usually doesn't use one unless you want
to get fancy with AVI animations like Windows file copy.

If the operation involves some kind of loop or the 'atomic' operation
exposes some kind of event that's fired routinely during the process,
then the UI can be updated from the loop or event handler.

That's quite commonly how it's done, because in the overhwelming
number of cases I've seen, progress UIs are blocking (e.g., the user
must either wait or cancel, but can't do anything else).

OTOH if this is more an 'adventure in programming' or threading for
threading's sake, then that's another matter, but the fact remains
the the problem is easily solvable without threading.


That's the end goal, to process a request that, when is firing on all cylinders, takes 3 - 5 seconds and then opens the drawing.  There are times, however, that it could take much longer, and I need to give the user feedback on progress as well as provide an option to cancel the request altogether.  I certainly have no desire to blow the user away, well, at least not most of them :-)

Quote
I don't think it's a good idea to simply blow the user away by switching to a newly opened document while they may be in the middle of doing just about anything (like dragging objects around, or perhaps have another dialog box open, or what have you).

In this instance, I agree.

This is not what I was reading into Bobby's original post. Having some type of background threading is a necessity if you are dealing with backend data sources. I read into Bobby's post that he wanted a long process to run then open a file and use a thread so the user could cancel the operation ...].
Bobby C. Jones