Re: sending events asynchronously

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.tp52edcn8jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Mon, 02 Apr 2007 05:15:07 -0700, colin <colin.rowe1@xxxxxxxxxxxxxxxxxx>
wrote:

Ah thats confusing if theres 2 ways its done. I found the article again
..
http://www.codeproject.com/csharp/AsyncMethodInvocation.asp

its a bit long. I havnt re-read it as yet.

Yes, it is confusing. It's my opinion that this kind of overloading is a
bad idea. For an environment that purports to try to make things simple
and prevent the programmer from doing the wrong thing, it's an oddity that
they don't do a better job distinguishing between these two
related-but-fundamentally-different behaviors.

I did find it a bit confusing to say the least.
But if it was explained with enough detail but in a concise way
that is easy to find it wouldnt be a problem.

[...]
I think there is a great deal more about .NET than I need to know to do
this. such as remote web stuff.
a quote from microsoft - "no one person can even keep up with the all the
changes"

I'm not saying you need to learn everything about .NET before you use it.
I'm saying that you can't expect it to be as quick as advertised until you
at least learn the parts you're going to use.

well im impatient lol cant help it !
well actually I didnt realy expect to write all the bits of code in 60
seconds each.
Im just pointing out the disparity between the ease of some parts and the
difficulty of other parts.
To my mind multi threading should be made as easy as adding a control,
although you can add a worker thread in 10 seconds,
it takes a great deal of time to find out how to get round the problem of
thread safe UI controls,
when it is actually quite easy to do, just takes a long time to get there.

I think the ability to make an app in 60 seconds from scratch just makes it
more frustrating when
other things take many days to find out how to do.

I remember how hard I found it to learn C initialy when I didnt know anyone
who knew it.

[...]
But again, it's not different from C/C++. There's no typedef in C#, so
the syntax is a little different. But the declaration of a delegate in C#
is almost exactly the same as that of a function pointer in C/C++, and
still results in a type being declared.

What do you see as different about the two that requires you to be
"convinced" that using delegates isn't any harder than function pointers
in C/C++?

hmm we're talking about two different things here,
the syntax of the delegate/function pointer wich I agree c# is effectivly
easier becuase it is more powerfull.
it lets you make a delegate of a block of code.

then theres the other issue of how its used for inter thread purposes,
wich took a little while to grasp becuase its not so clear.

[...]
Deadlocks are always an issue, and I don't see how a language can
prevent
them. Perhaps one day, if someone figures out how to make a computer
program provably correct, we'll get a compiler that does that. Until
then, we're left with the problem that computer programs can be
arbitrarily complex and preventing deadlocks isn't possible.

With traditional way of thinking about flow of code yes I agree.

If you have a non-traditional way of thinking about flow of code in which
you can prove the absence of possibility of deadlock, you should publish
your results. This is something computer scientists have been working on
for a long time without any positive results.

well I dont have anything new im sure,
but if you take the methodolgies such as state machines and data
transformations
one step further and instead of writing code wich does it all in one or more
threads,
you just have functions wich just do transformations or
functions wich just drive state machines,
where all the data being passed in and out is done through the top level
parameters.
a seperate body does all the data passing and thread to task assigning etc.

It should be easier to prove/avoid any deadlocks.

ofc this could easily be done with just a strict guidline in any language.
I did try to push a project I was working on in this direction,
for wich I had written a real time threading executive,
but most people seemed dumbfounded by the idea.

I dont realy agree its a win32 issue, maybe im a bit rusty I havnt used
raw win32 for a decade,
so forgive me if im wrong but you could post a message to any control
from any task and as long as the handle was still valid it went into the
system and magically re apeared at the main message pump loop of the
thread
that created the control.

Yes, you could. And still can. That's not a counter-example to the
cross-thread issue. For example, when you set the Text property of a
Control instance, you aren't posting a message. You're sending it.
SendMessage occurs on the same thread, bypassing the message queue.

This was illegal to do from a different thread in Win32 and it's still
illegal in .NET.


[...]
as far as I recall it was the advent of MFC with C++ wich cuased
problems to the unwary due to mfc window control classes in particular
using temporary data structures wich could get de-allocated when the
main loop became idle.
thus they were not always safe to access from outside the main thread.

This isn't an MFC issue, nor did MFC have the issue you describe above.
All direct access of windows has always been unreliable when done from a
thread other than the window's thread. PostMessage has always been the
required mechanism to access a window from a thread other than it's own
(well, for as long as threads have been in Windows anyway).

hmm thought win32 SendMessage always ensured the function ran on the thread
for that control.
post mesage is the same exept it returns imediatly where as send waits for
the function to return;

with MFC though you tend to call the individual message proccessing function
directly therefore bypassing the thread switching, wich is probably more
efficient on the same thread, but is not safe from another thread.
the problem is there is then no nice wrapper around the method of sending
the set text message via windows.

however I now know BeginInvoke can easily provide that functionailty in c#.
instead of just complaing about non thread safe calls it could provide this
inside the control
or at least give
tel you tel you let you know tell you give more readily available help in
how to do it.


Pete

Colin =^.^=


.

Relevant Pages

  • Re: How can I use C# GUI component in my MFC application.
    ... Here's some stuff I had written on this topic for my book (Extending MFC ... Using a .NET control in an MFC dialog ... we have seen how Windows Forms makes GUI development slightly easier ... BOOL Create(CWnd* pWnd, int x, int y, int cx, int cy); ...
    (microsoft.public.dotnet.languages.vc)
  • Re: MFC Migration/Integration
    ... I cross post my somewhat frustrated question on MFC ... Check Box, Edit Control, Combo Box, ... List Box, Group Box, Radio Button, Static Text, Picture Control, ... object-oriented techniques (MFC Version 8 with Windows Forms??). ...
    (microsoft.public.vc.mfc)
  • Re: WM_PAINT NON-STOP IN CUSTOM CONTROL
    ... advantages and still have the ability to create your own custom control (not ... And this is different from what MFC supports naturally in exactly what way? ... of Windows programming and still don't know how Windows works;))).. ... BeginPaint, ...
    (microsoft.public.vc.mfc)
  • Re: Form
    ... "full control" exhibits a lack of maturity I have not seen in many years. ... I wrote in Win32 for five years before I started using MFC, and I have not written a Win32 ... I told one client that my hourly rate would double to write a Win32-based Windows program, ...
    (microsoft.public.vc.mfc)
  • Re: need data capture, stat analysis, graph display software for PC
    ... I found a Queue wich can transfer objects between threads ... cant even send them as simple windows event messages like with mfc. ... anything -- just have each class set up its event handlers in the ... solution for people that didnt want to write thread safe code, ...
    (sci.electronics.design)