Hmm.
I think I'm finished here, you've clearly hit a point where you cannot
logically argue, so you're throwing out a few one-liners.
I can't help but to point out that your initial argument was "just do what
works for you", and now you are attempting to back that up by suggesting
that I go read about what other people are doing.
Hmm.
But beyond that, I would love to hear your explanation of exactly what you
think these newsgroups are for.
Personally, I use them as a resource for seeking answers to general
questions, so that I can tune my research, and as airing platform so that I
can get reality checks on technical and design decisions, and as an
opportunity to poll the experience of other professionals when I feel it
appropriate.
I also try to repay the community by providing constructive, helpful
responses when I encounter someone with a problem that I am familiar with.
Oh, and since I do pay for MSDN Universal, which includes newsgroup support,
I feel completely entitled to post a question when one arises.
"Alvin Bruney" <al**********@t elia.com> wrote in message
news:OS******** *****@TK2MSFTNG P11.phx.gbl...
Its called MSDN, go read it.
"J.Marsch" <je****@ctcdeve loper.com> wrote in message
news:Oy******** ******@TK2MSFTN GP10.phx.gbl... Well, with all due respect (though you've shown me none). What works
for me may not work for Windows. If I'm about to make a design decision that will affect the architecture of a UI layer that will be used in multiple
applications, and as the basis for the design of hundreds of forms,
don't you sort of think that it would be a good idea to make sure that the
threading model is compatible with the Windows UI layer???
That's called called due dilligence and common sense, Alvin.
If you don't have anything useful to add to this conversation, why
don't you just crawl back under whatever rock you came out from under.
"Alvin Bruney" <al**********@t elia.com> wrote in message
news:eX******** ******@TK2MSFTN GP10.phx.gbl... Do what works for you. Why Must you follow everybody else when you're
solution is for you.
If I told you to shove yer hand in the oven , would you? Or cut on yer
gonads?
"J.Marsch" <je****@ctcdeve loper.com> wrote in message
news:#w******** ******@TK2MSFTN GP12.phx.gbl...
> Thank you all for your input, but there's a fine point here that I'm
trying
> to close in on. We are on the same page regarding Invoke and that the > "owning" thread must fire events on the control, and I agree that
this is a
> Windows issue, not winforms.
>
> What I'm lost on:
> What would be best practice for instancing a form? In my example, a
> background thread will possibly need to throw up a form in response
to a > system event. When that happens, from a best-practice point of
view, am I > ok just instancing a form on the spot, or am I better off creating a
pattern
> that will cause the form to be created on the application's Main thread? >
> ""Jeffrey Tan[MSFT]"" <v-*****@online.mi crosoft.com> wrote in
message > news:ub******** ******@cpmsftng xa07.phx.gbl...
> >
> > Hi,
> >
> > In winform, controls in Windows Forms are bound to a specific
thread and > > are not thread safe.
> > There are four methods on a control that are safe to call from any
thread:
> > Invoke, BeginInvoke, EndInvoke and CreateGraphics. For all other method > > calls, you should use one of these invoke methods when calling
from a > > different thread.
> >
> > The sample below tells you how to manipulate multithreading
winform > > controls:
> >
>
http://msdn.microsoft.com/library/de...us/cpguide/htm > > l/cpconDeveloping MultithreadedWi ndowsFormsContr ol.asp
> >
> > Hope this helps,
> > Best regards,
> > Jeffrey Tan
> > Microsoft Online Partner Support
> > Get Secure! - www.microsoft.com/security
> > This posting is provided "as is" with no warranties and confers no
rights.
> >
>
>
