|
may it can help you out
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzalu/rzaluroutingexamples.htm
|
|
|
|
|
I have added a DataGridViewButtonColumn to one of the columns of a grid.How to change the colour of a button in DataGridViewButtonColumn?
|
|
|
|
|
This is part of the code from the DataGridViewColumn Class entry on MSDN.
int thirdColumn = 2;
DataGridViewColumn column =
dataGridView.Columns[thirdColumn];
DataGridViewCell cell = new DataGridViewTextBoxCell();
cell.Style.BackColor = Color.Wheat;
column.CellTemplate = cell;
Now this obviously works for a DataGridViewTextBoxCell, whether it would work for a DataGridViewButtonCell I don't know. but give it a try.
Henry Minute
If you open a can of worms, any viable solution *MUST* involve a larger can.
|
|
|
|
|
I'm trying to set a VS setup project to use the client profile as the prerequisite. I've had successfull setup project builds using as a prerequisite 3.5 and 3.5 sp1, but i'm getting error:
The install location for prerequisites has not been set to 'component vendor's web site' and the file 'DotNetFx35Client\DotNetFx35ClientSetup.exe' in item '.NET Framework Client Profile' can not be located on disk.
I've completed the setup mentioned in MS's 3.5 sp1 readme (section 2.3.1.1).
So how do set the client profile as the prerequisite? Do i need to create and edit a "Deployment.xml" file? If so where does it go?
|
|
|
|
|
It seems that the default stack size for a new thread in .NET under Windows 2003 server has been reduced. This causes problems for any application that needs to implement extended recursion. I know that I can specify the stack size when explicitly creating threads, but I have not been able to figure out how to specify the stack size if I am using the ThreadPool.
Any help will be appreciated.
|
|
|
|
|
Concurrent Programming on Windows[^] says that the threadpool threads pick the default stack size in the PE header. You can change that using the editbin utility.
Open VS 200X command prompt and type editbin.exe. You should see a /STACK command line switch that lets you set the max reserve and initial commit sizes of the stack.
|
|
|
|
|
While Senthil's suggestion should work, I would suggest that you take a look at why you are running out of stack space. Frequently, this would be an indication of a design flaw somewhere. Excessive recursion maybe along with large value type variables and/or method arguments? Re-factoring the code to not be so stack-dependent maybe an option to consider.
--
gleat
http://blogorama.nerdworks.in[ ^]
-- Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
|
|
|
|
|
I have read in many posts that windows 2003 reduced the thread stack size from 1M to 256K. any application that needs above average recursion will run into this limit sooner or later. My application has such a recursion built into it. I appreciate your recommendation of design inspection. Although I will check that again, I do not believe that a design flaw is causing this. Also no large data is passed around.
|
|
|
|
|
Hi,
IMO recursion is a dangerous technique: the stack size is limited, the complexity of the problem you are trying to solve might not be. Even if you had 16MB of stack, what guarantee do you have your app will cope with the situations that may arise in future?
When the design remains unchanged, you may try and alleviate the problem by reducing the stack size needed for each recursion level, basically look for local value types and try and replace them by reference types if at all possible. At best you would find a large struct and simply turn it into a class; or a bunch of simple variables, and group them into a class. That way, a lot of your recursive data gets moved to the heap (at the expense of some performance reduction).
|
|
|
|
|
Good advice. I was going to suggest that starting from .NET 3.5 SP1, the CLR can inline method calls with value types and so turning value types into reference types might not help much. That's when I realized that we are talking about recursive methods. 
|
|
|
|
|
As Luc has explained, with recursion it is often difficult to predict when an input may arrive that causes the recursive routine to cross stack space limits (no matter how high it is) which makes determining the right amount of stack space needed somewhat tricky.
I wasn't aware however that they'd reduced the default stack space on 2003 server for threads by 1/4th of what it normally is! And given that it doesn't seem to have created as much of an uproar as it might have, maybe they should reduce the default on desktops too!
--
gleat
http://blogorama.nerdworks.in[ ^]
-- Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
|
|
|
|
|
Hi,
whatever we think about recursion, I fail to understand why Microsoft reserves the right to specify a maximum stack size at all; if an app is allowed to allocate regular memory for whatever purpose (from malloc to the largest new SomeThing), then why can't the app developer not be trusted of setting his own maximum stack size? It is after all his responsibility not to run out of physical memory. virtual memory,
address space, and what have you. What is so special about a stack? Having a rather low default value may be fine, as it protects against one kind of mishaps, but it should not be cast in stone.
Or: what is the difference between a single thread with an unlimited stack, and a huge number of threads with a limited stack?
|
|
|
|
|
I completely agree with Luc's comments. I am not sure if MS changed that limit consciously prevent mishaps or if they reduced it as a fix to some internal issue with resource management.
In any case, if the application handles the thread management, you can set the stack size for each thread you create, I don't understand why they did not provide that ability when you use the ThreadPool.
|
|
|
|
|
I thought the developer is allowed to specify the stack size (dwStackSize parameter of CreateThread, stack_size parameter of _beginthreadex and the overload of the Thread class constructor that accepts a maxStackSize parameter). In this particular case since the actual thread creation is controlled by ThreadPool there doesn't seem to be any way of explicitly specifying the stack size for the threads created by the pool. Maybe they should have left this as a configuration parameter for ThreadPool objects - which would have been more .NETish if you like, instead of having to mess with PE headers!
--
gleat
http://blogorama.nerdworks.in[ ^]
-- Number Two's eyes narrowed and became what are known in the Shouting and Killing People trade as cold slits, the idea presumably being to give your opponent the impression that you have lost your glasses or are having difficulty keeping awake. Why this is frightening is an, as yet, unresolved problem. -- HHGTG
|
|
|
|
|
gleat wrote: Maybe they should have left this as a configuration parameter for ThreadPool objects - which would have been more .NETish if you like, instead of having to mess with PE headers!
It is probably because it would be too late - AFAIK, threadpools are created pretty early in the process lifecycle.
|
|
|
|
|
Right. I was thinking something in a .config file might have helped. I actually got somewhat excited by this and started reflecting[^] my way through "mscorlib" when I suddenly remembered that I had a ton of work to do and I hadn't even gotten started yet! 
|
|
|
|
|
kiran_sr wrote: windows 2003 reduced the thread stack size from 1M to 256K
Where does that information come from?
AFAIK, a system thread stack size is determined by the creator of the thread, or the default in the executable header.
That still doesn't apply to .NET threads, since there's no one-to-one correlation
between Thread objects and system threads. However, using the Thread constructor that takes a
maxstacksize should have the same behavior as directly creating system threads, with the following caveat:
"On versions of Microsoft Windows prior to Windows XP and Windows Server 2003, maxStackSize
is ignored, and the stack size specified in the executable header is used."
If you need more stack than a threadpool thread provides then a threadpool thread is not
appropriate. An explicit Thread is more appropriate.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
I need to change the means increase Trust level for Trusted site.
I can use the .NET Framework 2.0 configuration tool on my PC but most PCs
don;t have this installed.
Can I use Caspol.exe for this? If so, I cannot see how.
Please Help me
Thanks in advance
Dattatraya 
|
|
|
|
|
Do these other machines have notepad? Do you have the ability read and XML document from your code?
only two letters away from being an asset
|
|
|
|
|
yes i can have it!
So what to do??
|
|
|
|
|
Hi all,
according to what i rad about boxing and valueType allocation -
When i define some Value Type ( like struck or int ) the CLR allocate memory on the stack.
When i boxing this valueType the create reference on the heap that will point on the variable that i already define on the stack.
My question is -
allocate memory on the stack is more effective then allocate on the heap ?
What is the benefit of allocate valueType on the stack ?
Thanks.
|
|
|
|
|
|
Perhapse he was 'struck' by an int? 
|
|
|
|
|
Yanshof wrote: When i define some Value Type ( like struck or int ) the CLR allocate memory on the stack.
That depends on where your value type is used. It will not always goes to stack.
Yanshof wrote: allocate memory on the stack is more effective then allocate on the heap ?
What is the benefit of allocate valueType on the stack ?
In .NET, you don't need to bother about the allocation like in C++. The run-time will take care about it. If you need to learn how memory is allocated in CLR, read this[^].
|
|
|
|
|
Dear All,
When im connecting wmi that error is coming.. how to i solve the problem.this is my coding.Any one can help me?
ConnectionOptions connection = new ConnectionOptions();
connection.EnablePrivileges = true;
ManagementScope scope = null;
domain = "abc.com";
connection.Authority = "NTLMDomain:" + domain;
connection.Username = userName;
connection.Password = password;
//Local Machine
if (compName.ToUpper() == Environment.MachineName.ToUpper())
{
scope = new ManagementScope(@"\root\cimv1", connection);
}
else //Remote Machine
{
scope = new ManagementScope(@""+ compName + @"\root\cimv1", connection);
}
try
{
scope.Options.EnablePrivileges = true;
scope.Connect();//Error User credentials cannot be used for local connections
ObjectQuery query = new ObjectQuery("SELECT * FROM Win32_OperatingSystem");
ManagementObjectSearcher objsearcher = new ManagementObjectSearcher(scope, query);
ManagementObjectCollection objcol = objsearcher.Get();
}
finally
{
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
