473,836 Members | 1,557 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Yet another threading/invoking question...

Hi,

I'm currently rewriting some functionality which was using
multithredaing for retrieving datasets from database and updating a grid
control. I found that the grids (Infragistics UltraGrid, though it
doesn't matter) were updated (i.e. grid.DataSource = dsDataSet;) and
used for different purposes in the worker thread, so now i'm wrapping
all those calls to grid's methods thru invoking which is a pain in the
a$$ considering number of different methods UltraGrid has. So i wanted
to see if for now i could leave some of those calls as is.

So my question is: is it really-really... and i mean REALLY bad to call:

object o = mygridcontrol.T ag;

from a worker thread even if i am 100% sure this "mygridcont rol" is not
going to be used in the UI thread at the same time as i make this call?

Consider this sample:

// Somewhere in the UI (main) thread:
mygridcontrol = new UltraGrid();
Thread t = new Thread(new ThreadStarter(U pdateFuncDelega te));
.... and no code after that...
// In wroker thread - in function UpdateFunc

object o = mygridcontrol.T ag;

//////////////////////////

I know it's really bad bad bad!!! But still...

Please don't tell me i shouldn't do that, i know that.
Just tell me - if control is not used at time when its method is called
from a worker thread - is it going to lead to an error or not?
And if yes, why?
Thank you!
MuZZy
Dec 23 '05
25 2529
Please correct me if I'm wrong, but AFAIK, SendMessage doesn't do any
marshalling to the owner's thread, it sort of directly calls the
window's WndProc. It's terribly unsafe to SendMessage anything from
another thread.

Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:eX******** ********@TK2MSF TNGP11.phx.gbl. ..
Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:O$***** ********@TK2MSF TNGP15.phx.gbl. ..

Willy Denoyette [MVP] wrote:

>Everythi ng boils down to one simple rule: "don't modify "window
>objects" associated with a Window Handle (HWND) from another thread
>than the thread that owns the Handle (the creator of the window class).
>Or otherwise stated, "Window Handles" have thread affinity. That means
>that only the creator thread should modify the associated UI element,
>but , and this answers your question, other threads are allowed to read
>properties , styles and other attributes in a thread safe manner.

Hm... how can you make sure you access a UI control's property/attribute
from a worker thread in a "thread safe" way other than using
Control.Inv oke/BeginInvoke? There is no way you could know from a worker
thread that the UI control is not being modified right this moment and
calling a property's getter will not give you a wrong result.

Note I should have been more explicit, what I meant was:
"other threads are allowed to read 'Window properties',
'Window styles' and other attributes in a thread safe manner." Note the
"Window" ...
This is true from the Window Manager's point of view (a native component
in user32.dll).
Let me explain with a sample.
Suppose you have a form with 'Label' control and you want to get it's
"Text" property. The way this is done is by calling user32
"GetWindowTe xt" API. This API takes the HWND of the Label control a
pointer to a buffer that will hold the test of the label after success
return and the length of the buffer. The function sends a WM_GETTEXT
window message to the owning thread message queue (the Handle<->thread
relation is maintained by the window manager - thread affinity
remember!) , where it will be handled by the WndProc.


What you describe here for Win32 processes is exactly what happens when i
call .NET's Control.Invoke/BeginInvoke - it sends a message via blocking
PostMessage or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Invok e, not obtaining them directly, eg

bool bVisible = button.Invoke(C heckVisibleDele gate);

... instead of

bool bVisible = button.Visible;

Right?

Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessage to pass a "private user message" to the windows message queue
and it puts a delegate in a private queue that will get fetched by the
WndProc when it processes the "private user message". The WndProc will call
the delegate target on it's own (correct) thread. What I described above
skips the first SendMesage and uses a single SendMessage to send WM_XXX
messages to retrieve the property. That means it is inherently faster.
Note again that this is no longer possible in V2 of the framework, but it's
how it can safely be done using the Win32 API's (and the native frameworks
like MFC, WFC and ATL).

Only in this case you can guarantee that you request doesn't get any
inconsisten t data

Correct. But see above.

Willy.

Dec 23 '05 #21
MuZZy wrote:
Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:eX******** ********@TK2MSF TNGP11.phx.gbl. ..
Willy Denoyette [MVP] wrote:

"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:O$******** *****@TK2MSFTNG P15.phx.gbl...

> Willy Denoyette [MVP] wrote:
>
>> Everything boils down to one simple rule: "don't modify "window
>> objects" associated with a Window Handle (HWND) from another
>> thread than the thread that owns the Handle (the creator of the
>> window class).
>> Or otherwise stated, "Window Handles" have thread affinity. That
>> means that only the creator thread should modify the associated UI
>> element, but , and this answers your question, other threads are
>> allowed to read properties, styles and other attributes in a
>> thread safe manner.
>
> Hm... how can you make sure you access a UI control's
> property/attribute from a worker thread in a "thread safe" way
> other than using Control.Invoke/BeginInvoke? There is no way you
> could know from a worker thread that the UI control is not being
> modified right this moment and calling a property's getter will not
> give you a wrong result.
>
>
Note I should have been more explicit, what I meant was:
"other threads are allowed to read 'Window properties',
'Window styles' and other attributes in a thread safe manner." Note
the "Window" ...
This is true from the Window Manager's point of view (a native
component in user32.dll).
Let me explain with a sample.
Suppose you have a form with 'Label' control and you want to get
it's "Text" property. The way this is done is by calling user32
"GetWindowT ext" API. This API takes the HWND of the Label control a
pointer to a buffer that will hold the test of the label after
success return and the length of the buffer. The function sends a
WM_GETTEXT window message to the owning thread message queue (the
Handle<->thread relation is maintained by the window manager -
thread affinity remember!), where it will be handled by the WndProc.

What you describe here for Win32 processes is exactly what happens
when i call .NET's Control.Invoke/BeginInvoke - it sends a message
via blocking PostMessage or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Invoke, not obtaining them directly, eg

bool bVisible = button.Invoke(C heckVisibleDele gate);

... instead of

bool bVisible = button.Visible;

Right?

Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessage to pass a "private user message" to the windows message
queue and it puts a delegate in a private queue that will get fetched
by the WndProc when it processes the "private user message". The
WndProc will call the delegate target on it's own (correct) thread.
What I described above skips the first SendMesage and uses a single
SendMessage to send WM_XXX messages to retrieve the property. That
means it is inherently faster.
Note again that this is no longer possible in V2 of the framework, but
it's how it can safely be done using the Win32 API's (and the native
frameworks like MFC, WFC and ATL).

Wow, wow hold on! What is "no longer possible in V2 of the framework" -
using Control.Invoke? Then i'll go hang on the tree, because i just
spent 10 hours in a row wrapping calls to controls using BeginInvoke.

Or did i miss something?

Only in this case you can guarantee that you request doesn't get any
inconsistent data


Correct. But see above.

Willy.

The 2.0 framework complains (in debug builds) about calls from non-UI
threads to control methods. This has nothing to do with
Control.Invoke/BeginInvoke (the methods wouldn't be of much use, if you
couldn't use them from any thread, would they?)

Stefan
Dec 23 '05 #22
No, SendMessage does marshaling for system messages(0-WM_USER), other
message types must be custom marshaled (think Control.Invoke/BeginInvoke).
The WndProc is only called directly (as a subroutine) when the SendMessage
thread is the same as the HWND owned thread (the one that created the
window), otherwise the system switches to the owning thread and puts thye
message into it's message queue where it will be picked-up by the right
thread's WndProc.
Please consult SendMessage API for more details.

Willy.

"Stefan Simek" <si**********@t riaxis.nospam.s k> wrote in message
news:OL******** *******@TK2MSFT NGP14.phx.gbl.. .
Please correct me if I'm wrong, but AFAIK, SendMessage doesn't do any
marshalling to the owner's thread, it sort of directly calls the window's
WndProc. It's terribly unsafe to SendMessage anything from another thread.

Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:eX******** ********@TK2MSF TNGP11.phx.gbl. ..
Willy Denoyette [MVP] wrote:

"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:O$**** *********@TK2MS FTNGP15.phx.gbl ...

>Willy Denoyette [MVP] wrote:
>
>>Everythin g boils down to one simple rule: "don't modify "window
>>objects " associated with a Window Handle (HWND) from another thread
>>than the thread that owns the Handle (the creator of the window
>>class).
>>Or otherwise stated, "Window Handles" have thread affinity. That means
>>that only the creator thread should modify the associated UI element,
>>but , and this answers your question, other threads are allowed to
>>read properties, styles and other attributes in a thread safe manner.
>
>Hm... how can you make sure you access a UI control's
>property/attribute from a worker thread in a "thread safe" way other
>than using Control.Invoke/BeginInvoke? There is no way you could know
>from a worker thread that the UI control is not being modified right
>this moment and calling a property's getter will not give you a wrong
>result.
>
>

Note I should have been more explicit, what I meant was:
"other threads are allowed to read 'Window properties',
'Window styles' and other attributes in a thread safe manner." Note the
"Window" ...
This is true from the Window Manager's point of view (a native component
in user32.dll).
Let me explain with a sample.
Suppose you have a form with 'Label' control and you want to get it's
"Text" property. The way this is done is by calling user32
"GetWindowT ext" API. This API takes the HWND of the Label control a
pointer to a buffer that will hold the test of the label after success
return and the length of the buffer. The function sends a WM_GETTEXT
window message to the owning thread message queue (the Handle<->thread
relation is maintained by the window manager - thread affinity
remember! ), where it will be handled by the WndProc.

What you describe here for Win32 processes is exactly what happens when i
call .NET's Control.Invoke/BeginInvoke - it sends a message via blocking
PostMessag e or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Invo ke, not obtaining them directly, eg

bool bVisible = button.Invoke(C heckVisibleDele gate);

... instead of

bool bVisible = button.Visible;

Right?

Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessage to pass a "private user message" to the windows message queue
and it puts a delegate in a private queue that will get fetched by the
WndProc when it processes the "private user message". The WndProc will
call the delegate target on it's own (correct) thread. What I described
above skips the first SendMesage and uses a single SendMessage to send
WM_XXX messages to retrieve the property. That means it is inherently
faster.
Note again that this is no longer possible in V2 of the framework, but
it's how it can safely be done using the Win32 API's (and the native
frameworks like MFC, WFC and ATL).

Only in this case you can guarantee that you request doesn't get any
inconsiste nt data

Correct. But see above.

Willy.


Dec 23 '05 #23

"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:e7******** ********@tk2msf tngp13.phx.gbl. ..
Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:eX******** ********@TK2MSF TNGP11.phx.gbl. ..
Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:O$******** *****@TK2MSFTNG P15.phx.gbl...
> Willy Denoyette [MVP] wrote:
>> Everything boils down to one simple rule: "don't modify "window
>> objects" associated with a Window Handle (HWND) from another thread
>> than the thread that owns the Handle (the creator of the window
>> class).
>> Or otherwise stated, "Window Handles" have thread affinity. That
>> means that only the creator thread should modify the associated UI
>> element, but , and this answers your question, other threads are
>> allowed to read properties, styles and other attributes in a thread
>> safe manner.
> Hm... how can you make sure you access a UI control's
> property/attribute from a worker thread in a "thread safe" way other
> than using Control.Invoke/BeginInvoke? There is no way you could know
> from a worker thread that the UI control is not being modified right
> this moment and calling a property's getter will not give you a wrong
> result.
>
>
Note I should have been more explicit, what I meant was:
"other threads are allowed to read 'Window properties',
'Window styles' and other attributes in a thread safe manner." Note the
"Window" ...
This is true from the Window Manager's point of view (a native
component in user32.dll).
Let me explain with a sample.
Suppose you have a form with 'Label' control and you want to get it's
"Text" property. The way this is done is by calling user32
"GetWindowT ext" API. This API takes the HWND of the Label control a
pointer to a buffer that will hold the test of the label after success
return and the length of the buffer. The function sends a WM_GETTEXT
window message to the owning thread message queue (the Handle<->thread
relation is maintained by the window manager - thread affinity
remember!), where it will be handled by the WndProc.
What you describe here for Win32 processes is exactly what happens when
i call .NET's Control.Invoke/BeginInvoke - it sends a message via
blocking PostMessage or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Invoke, not obtaining them directly, eg

bool bVisible = button.Invoke(C heckVisibleDele gate);

... instead of

bool bVisible = button.Visible;

Right?


Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessage to pass a "private user message" to the windows message queue
and it puts a delegate in a private queue that will get fetched by the
WndProc when it processes the "private user message". The WndProc will
call the delegate target on it's own (correct) thread. What I described
above skips the first SendMesage and uses a single SendMessage to send
WM_XXX messages to retrieve the property. That means it is inherently
faster.
Note again that this is no longer possible in V2 of the framework, but
it's how it can safely be done using the Win32 API's (and the native
frameworks like MFC, WFC and ATL).


Wow, wow hold on! What is "no longer possible in V2 of the framework" -
using Control.Invoke? Then i'll go hang on the tree, because i just spent
10 hours in a row wrapping calls to controls using BeginInvoke.

Or did i miss something?


I'm not talking about Control.Invoke/BeginInvoke, I was talking about
accessing window properties directly from a non owning thread.

Something like:
// read Text property from non label1 owning thread
string lblTest = label1.Text;
Willy.
Dec 23 '05 #24
Thanks a lot, I should have read the documentation before I posted...

Willy Denoyette [MVP] wrote:
No, SendMessage does marshaling for system messages(0-WM_USER), other
message types must be custom marshaled (think Control.Invoke/BeginInvoke).
The WndProc is only called directly (as a subroutine) when the SendMessage
thread is the same as the HWND owned thread (the one that created the
window), otherwise the system switches to the owning thread and puts thye
message into it's message queue where it will be picked-up by the right
thread's WndProc.
Please consult SendMessage API for more details.

Willy.

"Stefan Simek" <si**********@t riaxis.nospam.s k> wrote in message
news:OL******** *******@TK2MSFT NGP14.phx.gbl.. .
Please correct me if I'm wrong, but AFAIK, SendMessage doesn't do any
marshalling to the owner's thread, it sort of directly calls the window's
WndProc. It's terribly unsafe to SendMessage anything from another thread.

Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:eX***** ***********@TK2 MSFTNGP11.phx.g bl...
Willy Denoyette [MVP] wrote:
>"MuZZy" <tn*@newsgroups .nospam> wrote in message
>news:O$*** **********@TK2M SFTNGP15.phx.gb l...
>
>
>>Willy Denoyette [MVP] wrote:
>>
>>
>>>Everythi ng boils down to one simple rule: "don't modify "window
>>>object s" associated with a Window Handle (HWND) from another thread
>>>than the thread that owns the Handle (the creator of the window
>>>class) .
>>>Or otherwise stated, "Window Handles" have thread affinity. That means
>>>that only the creator thread should modify the associated UI element,
>>>but , and this answers your question, other threads are allowed to
>>>read properties, styles and other attributes in a thread safe manner.
>>
>>Hm... how can you make sure you access a UI control's
>>propert y/attribute from a worker thread in a "thread safe" way other
>>than using Control.Invoke/BeginInvoke? There is no way you could know
>
>>from a worker thread that the UI control is not being modified right
>
>>this moment and calling a property's getter will not give you a wrong
>>result.
>>
>>
>
>Note I should have been more explicit, what I meant was:
>"other threads are allowed to read 'Window properties',
>'Window styles' and other attributes in a thread safe manner." Note the
>"Window" ...
>This is true from the Window Manager's point of view (a native component
>in user32.dll).
>Let me explain with a sample.
>Suppose you have a form with 'Label' control and you want to get it's
>"Text" property. The way this is done is by calling user32
>"GetWindow Text" API. This API takes the HWND of the Label control a
>pointer to a buffer that will hold the test of the label after success
>return and the length of the buffer. The function sends a WM_GETTEXT
>window message to the owning thread message queue (the Handle<->thread
>relation is maintained by the window manager - thread affinity
>remember!) , where it will be handled by the WndProc.

What you describe here for Win32 processes is exactly what happens when i
call .NET's Control.Invoke/BeginInvoke - it sends a message via blocking
PostMessa ge or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Inv oke, not obtaining them directly, eg

bool bVisible = button.Invoke(C heckVisibleDele gate);

... instead of

bool bVisible = button.Visible;

Right?
Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessag e to pass a "private user message" to the windows message queue
and it puts a delegate in a private queue that will get fetched by the
WndProc when it processes the "private user message". The WndProc will
call the delegate target on it's own (correct) thread. What I described
above skips the first SendMesage and uses a single SendMessage to send
WM_XXX messages to retrieve the property. That means it is inherently
faster.
Note again that this is no longer possible in V2 of the framework, but
it's how it can safely be done using the Win32 API's (and the native
frameworks like MFC, WFC and ATL).

Only in this case you can guarantee that you request doesn't get any
inconsisten t data

Correct. But see above.

Willy.


Dec 23 '05 #25
Stefan Simek wrote:
MuZZy wrote:
Willy Denoyette [MVP] wrote:
"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:eX******** ********@TK2MSF TNGP11.phx.gbl. ..

Willy Denoyette [MVP] wrote:

> "MuZZy" <tn*@newsgroups .nospam> wrote in message
> news:O$******** *****@TK2MSFTNG P15.phx.gbl...
>
>> Willy Denoyette [MVP] wrote:
>>
>>> Everything boils down to one simple rule: "don't modify "window
>>> objects" associated with a Window Handle (HWND) from another
>>> thread than the thread that owns the Handle (the creator of the
>>> window class).
>>> Or otherwise stated, "Window Handles" have thread affinity. That
>>> means that only the creator thread should modify the associated
>>> UI element, but , and this answers your question, other threads
>>> are allowed to read properties, styles and other attributes in a
>>> thread safe manner.
>>
>> Hm... how can you make sure you access a UI control's
>> property/attribute from a worker thread in a "thread safe" way
>> other than using Control.Invoke/BeginInvoke? There is no way you
>> could know from a worker thread that the UI control is not being
>> modified right this moment and calling a property's getter will
>> not give you a wrong result.
>>
>>
> Note I should have been more explicit, what I meant was:
> "other threads are allowed to read 'Window properties',
> 'Window styles' and other attributes in a thread safe manner." Note
> the "Window" ...
> This is true from the Window Manager's point of view (a native
> component in user32.dll).
> Let me explain with a sample.
> Suppose you have a form with 'Label' control and you want to get
> it's "Text" property. The way this is done is by calling user32
> "GetWindowT ext" API. This API takes the HWND of the Label control a
> pointer to a buffer that will hold the test of the label after
> success return and the length of the buffer. The function sends a
> WM_GETTEXT window message to the owning thread message queue (the
> Handle<->thread relation is maintained by the window manager -
> thread affinity remember!), where it will be handled by the WndProc.

What you describe here for Win32 processes is exactly what happens
when i call .NET's Control.Invoke/BeginInvoke - it sends a message
via blocking PostMessage or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Invoke, not obtaining them directly, eg

bool bVisible = button.Invoke(C heckVisibleDele gate);

... instead of

bool bVisible = button.Visible;

Right?
Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessage to pass a "private user message" to the windows message
queue and it puts a delegate in a private queue that will get fetched
by the WndProc when it processes the "private user message". The
WndProc will call the delegate target on it's own (correct) thread.
What I described above skips the first SendMesage and uses a single
SendMessage to send WM_XXX messages to retrieve the property. That
means it is inherently faster.
Note again that this is no longer possible in V2 of the framework,
but it's how it can safely be done using the Win32 API's (and the
native frameworks like MFC, WFC and ATL).

Wow, wow hold on! What is "no longer possible in V2 of the framework"
- using Control.Invoke? Then i'll go hang on the tree, because i just
spent 10 hours in a row wrapping calls to controls using BeginInvoke.

Or did i miss something?

Only in this case you can guarantee that you request doesn't get any
inconsistent data
Correct. But see above.

Willy.

The 2.0 framework complains (in debug builds) about calls from non-UI
threads to control methods.


And that's cool - i hope it will stop some brickheads in our department
from making me fix their code :)
This has nothing to do with
Control.Invoke/BeginInvoke (the methods wouldn't be of much use, if you
couldn't use them from any thread, would they?)


That's why i was surprised...
Dec 23 '05 #26

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

19
6498
by: Jane Austine | last post by:
As far as I know python's threading module models after Java's. However, I can't find something equivalent to Java's interrupt and isInterrupted methods, along with InterruptedException. "somethread.interrupt()" will wake somethread up when it's in sleeping/waiting state. Is there any way of doing this with python's thread? I suppose thread interrupt is a very primitive functionality for stopping a blocked thread.
7
1196
by: Norbert | last post by:
Hello *, i am experimenting with threads and get puzzling results. Consider the following example: #-------------------- import threading, time def threadfunction(): .....print "threadfunction: entered" .....x = 10 .....while x < 40:
0
1195
by: Sam | last post by:
I'm using Python 2.3.5 with pygtk 2.4.1, and I'm using the second threading approach from pygtk's FAQ 20.6 - invoking "gtk.gdk.threads_init()", and wrapping all gtk/gdk function calls with gtk.threads_enter()/gtk.threads_leave() I start a thread, via thread.Threading.start(). The thread then calls a particularly time consuming C function, from an extension module. I find that when the thread is running the C code, the GUI hangs even...
4
1545
by: Mark Huebner | last post by:
My reply e-mail address was wrong in the prior message. Sorry about that. The following sample code for the lock statement is on page 112 of the O'Reilly book "C# Essentials". Can somebody explain to me why this recursive class definition of LockTest does not cause an infinite number of LockTest objects to be created (i.e., until it consumes all available memory)? I don't understand why only two threads are created. using System;
2
275
by: Jason MacKenzie | last post by:
I'm attempting to write data to our SAP system in VB.Net. The problem is that in certain situations, my app will hang until SAP has resources available. This causes huge problems for us the issue isn't noticed until our inventory people call in a panic. Is there a way I can use threading to throw an exception if its been hung on that line for over a minute? If this is not applicable I'm open to any suggestions.
14
2962
by: Christian Kaiser | last post by:
We have a component that has no window. Well, no window in managed code - it uses a DLL which itself uses a window, and this is our problem! When the garbage collector runs and removes our component (created dynamically by, say, a button click, and then not referenced any more), the GC runs in a different thread, which prohibits the DLL to destroy its window, resulting in a GPF when the WndProc of that window is called - the code is gone...
11
2221
by: Steve Smith | last post by:
I have written a winforms application that launches approximately 150 threads with Thread.ThreadStart() Each thread uses CDO 1.21 to logon to a different Exchange mailbox and send/receive a number of mail messages, reporting back to the UI thread through the use of a Queue object. When all messages that are expected have been received, each thread sends a final update to the UI and the method should exit, which should terminate the...
7
339
by: Phill W. | last post by:
Can anyone recommend a good reference on Threading (Framework 1.1)? I'm particularly confused about how to call a method in my "main" thread from another one. - or more, one day ;-) I've tried creating delegates to main thread methods and Invoking them and BeginInvoking them, but I've had some quite /horrendous/ results ... TIA,
2
2075
by: akameswaran | last post by:
Admittedly this problem causes no actual functional issues aside from an occasional error message when the program exits. The error is: Unhandled exception in thread started by Error in sys.excepthook: Original exception was: Yes all that info is blank. The application is a console application that is waiting for some condition on the machine to happen. However, I leave open the possiblitiy to cancel by a single key press at which
0
9673
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10859
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10560
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10602
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9388
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
6984
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5653
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
4023
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3116
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.