473,836 Members | 1,498 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 2525
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 however that in v2, a cross thread exception will get thrown (debug
build) even if you read properties from the non owning thread, IMO this is
too restrictive, but I know why it's been done that way.
UI objects that do not have thread affinity are, menus, icons and cursors,
here again multiple threads may access them but you need to coordinate
accesses (you may not modify a menu while another thread is displaying it).

Willy.

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.mach in AT dot.state.fl.us > wrote
in message news:O2******** ******@TK2MSFTN GP15.phx.gbl...
Hi,
So my question is: is it really-really... and i mean REALLY bad to call:

object o = mygridcontrol.T ag;

What is wrong with that? IF this call is made after the binding you should
get your value correctly, I do not think that Tag changes after a binding.

What you cannot do frmo a thread is the opposite:

mygridcontrol.T ag = o;
Then is when you can get problems
BTW, what does UltraGrid.Tag returns?


--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


Dec 23 '05 #11
Jon Skeet [C# MVP] wrote:
MuZZy <tn*@newsgroups .nospam> wrote:

<snip>
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?


I wouldn't like to say for sure whether it will lead to an error. I'd
have thought the fact that you know you shouldn't do it would be enough
to make you not do it, however. After all, even if it works in test,
you could easily get an issue on a customer box, by which time it's too
late to do it properly.


That has actually happened on a customer box, that's how i came across
this problem... It's better to do it right late than never :)

MuZZy
Dec 23 '05 #12
Abubakar wrote:
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?
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?


[in my opinion]: I think its not only "your code" that you can check and
guarantee wont touch the grid while your worker thread is updating it. It
could be windows framework's code accessing your grid at a time you dont
anticipate, like painting the grid. I'm not sure that it really happens what
I said about painting grid by the framework, but I'm sure things like this
happens and thats why people have problems while they access there UI
controls from other than there owning thread cuz "some times" that code
works and "sometimes" it doesnt. But thats what happen in race conditions,
sometimes they arise and sometimes they dont. So why not follow the discrete
rules and do yourself a favor by doing the invoking work that u r doing
right now. It'll benifit you in the future. As Jon said, your code may not
work on your customer's box. Imagine what will happen than.


I agree. It's just that yesterday when i was looking at the whole code
and realized that i need to re-do the whole Worker thread/UI controls
interaction i got a bit overwhelmed, but now after a sleepless night it
seems like a solvable task. I have to change some logic here and there
to make number of different calls from Worker thread to UI limited and
also in some cases i will have to use synchronous invocation but overall
it now doesn't seem as scary as yesterday :)
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


also you dont have to call "all" the methods of the grid in the working
thread, try changing some logic, like just call one function through invoke
and there do the rest.

Ab.

"MuZZy" <tn*@newsgroups .nospam> wrote in message
news:un******** ******@TK2MSFTN GP09.phx.gbl...
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 #13
MuZZy wrote:
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

Thank you all guys for your replies, now i have a concrete picture.

Actually one more question - is it anyhow different for UI thread if i
use sync invocation (Control.Invoke ) instead of async one
(Control.BeginI invoke). I know it will block the worker thread, but i
don't think it will be any different for UI thread, right?

And again, thanks for all you comments
MuZZy

Dec 23 '05 #14
Ignacio Machin ( .NET/ C# MVP ) wrote:
Hi,
So my question is: is it really-really... and i mean REALLY bad to call:

object o = mygridcontrol.T ag;


What is wrong with that? IF this call is made after the binding you should
get your value correctly, I do not think that Tag changes after a binding.

What you cannot do frmo a thread is the opposite:

mygridcontrol.T ag = o;
Then is when you can get problems
BTW, what does UltraGrid.Tag returns?


It's Control.Tag :)
Dec 23 '05 #15

"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. That means that an 'update' of the label can never "interfere" with
a 'read' of the text (a string), so it's thread safe right? !!Note that this
doesn't apply to simultaneous updates!!
Now, back to Windows.Forms. You know that WF sits in top of Win32 or in top
of user32's provided window services. So what WF does to read a Text
property from a Label is exactly what I described above, but it does more.
It can cache (some) properties in an internal cache to speed up fetches.
Accesses to the internal cache are not synchronized by the framework (it
would defeat the purpose of the caching), that means it's not 'thread safe'
to access them from multiple threads, this is not such a problem other than
you may read old or inconsistent data from a control, but it will never
cause deadlocks as is the case with multiple updates of UI control elements.
However, as I said before, v2 of the framework will throw an exception if
you read a property from a non-owning thread (see my previous reply).

Willy.


Dec 23 '05 #16
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?
Only in this case you can guarantee that you request doesn't get any
inconsistent data
That means that an 'update' of the label can never "interfere" with
a 'read' of the text (a string), so it's thread safe right? !!Note that this
doesn't apply to simultaneous updates!!
Now, back to Windows.Forms. You know that WF sits in top of Win32 or in top
of user32's provided window services. So what WF does to read a Text
property from a Label is exactly what I described above, but it does more.
It can cache (some) properties in an internal cache to speed up fetches.
Accesses to the internal cache are not synchronized by the framework (it
would defeat the purpose of the caching), that means it's not 'thread safe'
to access them from multiple threads, this is not such a problem other than
you may read old or inconsistent data from a control, but it will never
cause deadlocks as is the case with multiple updates of UI control elements.
However, as I said before, v2 of the framework will throw an exception if
you read a property from a non-owning thread (see my previous reply).

Willy.


Dec 23 '05 #17

"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).
Only in this case you can guarantee that you request doesn't get any
inconsistent data


Correct. But see above.

Willy.
Dec 23 '05 #18
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.

Dec 23 '05 #19
I just want to add to it, that you can check the .NET code of the stock
controls using reflector, but all that you'll get out of it is the fact
that many methods/properties end up as WinAPI calls. From there, it's
absolutely hopeless to try and analyse what will happen when you call
these from different threads. I remember having terrible problems in my
MFC days with GetWindowText and the likes, until I have learned that you
have to marshall calls to the UI thread to this (which was lots of fun
back then).

Just my 2c.
Stefan

Jon Skeet [C# MVP] wrote:
<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.mach in AT
dot.state.fl.us >> wrote:
No - strictly speaking, your not meant to even *access* properties on a
non-UI thread. In this case it would *probably* be okay, but I
certainly wouldn't want to risk it.


Do you have a concrete example of accesing a property of one of the stock
controls can create problems?

Not off-hand - but the documentation for Control clearly states:

<quote>
Only the following members are thread safe: BeginInvoke, EndInvoke,
Invoke, InvokeRequired, and CreateGraphics.
</quote>

If the accessors were guaranteed to be thread-safe, I'd have expected
that to be documented too.

It should only matters if the accesor makes some changes in the internal
status of the object.

Or if the accessor uses some internal state which may be in the process
of changing while it is being accessed...

Dec 23 '05 #20

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
9671
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
10846
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
10551
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
10595
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
6979
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
5828
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4458
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4021
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.