|
Thanks for your reply.
The code which you sent changing the back color of a row, wherever I click in the gridview.
So entire grid resulted in red background color
My issue is to change the selected background color. To describe more, If I click on first row, background color should change to Dark Gray color. after that, if I click on second row, first row should get reverted to previous color and second row background color should be in darkgray color.
|
|
|
|
|
Do you expect me to do everything for you?
Keep a "I changed this" row index, and change it back. Then set the new row, and save the index. It's not exactly rocket science...
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
|
|
|
|
|
Strange how we both chose Red.
|
|
|
|
|
Easy to type!
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
|
|
|
|
|
Set your row default selection colour in your form design, or add the following during initialisation:
gridView.Rows[e.RowIndex].DefaultCellStyle.SelectionBackColor = Color.Red;
And add something similar to the following to your cell click event:
gridView.Rows[e.RowIndex].Selected = true;
|
|
|
|
|
In CellClick event, below statement worked. Thank you.
dgvTestCaseDetails.Rows[e.RowIndex].Selected = true;
|
|
|
|
|
Hi friends,
I am trying to write a log file by using log4net, which should write all log events in default event log. Please help me to do it.
Thanks and Regards
Venkat
|
|
|
|
|
|
|
The same as usually. The Dispose method is called on the objects named in the Using statement.
ThreadAbort raises an exception in the specified thread. It's not an immediate termination of the thread.
|
|
|
|
|
Dave Kreskowiak wrote: The same as usually.
I don't like "Usually" ...
I read from somewhere that [^]lock(x) statement is syntactic sugar, that JIT compiler will autogenerate the following:
<br />
Monitor.Enter(o);<br />
S0;<br />
try {<br />
S1;<br />
} finally {<br />
Monitor.Exit(o);<br />
}<br />
However, for some compiler architecture, your code will not cleanup properly if Thread.Abort called at point "S0" above before the generated try block, thus Monitor.Exit will not be exited.
But hold - I just found out the answer - I missed the update from the referenced post which says M$ corrected the problem:
<br />
Update 4/17/08: This was indeed fixed for the X64 JIT in Visual Studio 2008. Note that when compiling C# code targeting both X86 and X64, if you do not use the /o+ switch, this problem can still occur due to extra explicit NOPs inserted before the try.<br />
<br />
The framework implements a method Monitor.ReliableEnter, by the way, that could be used to avoid orphaning locks in the face of thread aborts, but it's internal to mscorlib.dll. It sets an out parameter within a region of code that cannot be interrupted by a thread abort, which the caller can then check inside the finally block. The acquisition then gets moved inside so that, if the CALL is reached, the finally block is guaranteed to always run. You'd then write this instead:<br />
<br />
bool taken;<br />
try {<br />
Monitor.ReliableEnter(o, out taken);<br />
S1;<br />
} finally {<br />
if (taken)<br />
Monitor.Exit(o);<br />
}<br />
Problem solved!
dev
modified 1-Feb-13 0:09am.
|
|
|
|
|
devvvy wrote: I don't like "Usually" ...
Mistyped. It should have been "usual".
|
|
|
|
|
no worries, anyway, I posted the link to the update where it says M$ fixes that issue with JIT so lock/using are both safe to use on a thread function (in context of Thread.Abort)
problem solved.
dev
|
|
|
|
|
Looks like M$ fixed that issue with releasing lock - I tested on Windows 8 64 bit zero miss.
Looks like we can conclude:
a. using/lock statements both compatible with Thread.Abort that both would release the resource before thread is dead.
b. Thread.Abort is no longer Evil (If all resources created on the Thread - user remember to release in catch or finally block)
<br />
class Program<br />
{<br />
static object obj = new object();<br />
<br />
static void Main(string[] args)<br />
{ <br />
try<br />
{<br />
for (int i = 0; i < 1000; i++)<br />
{<br />
Thread thRun = new Thread(new ThreadStart(ThreadFunc));<br />
thRun.Start();<br />
<br />
Thread.Sleep(300);<br />
<br />
thRun.Abort();<br />
<br />
lock (obj)
{<br />
Console.WriteLine(i + ": Done locking obj from main");<br />
}<br />
}<br />
<br />
Console.WriteLine("Hit any key to exit");<br />
Console.ReadLine();<br />
}<br />
catch (Exception Ex)<br />
{<br />
Console.WriteLine("Error in main: " + Ex.Message);<br />
}<br />
<br />
return;<br />
}<br />
<br />
static void ThreadFunc()<br />
{<br />
lock (obj)<br />
{<br />
using (DataContainer SomeContainer = new DataContainer())<br />
{<br />
Console.WriteLine("ThreadFunc lock begins");<br />
Thread.Sleep(1000 * 10);<br />
}<br />
}<br />
Console.WriteLine("ThreadFunc lock released");<br />
<br />
return;<br />
}<br />
}<br />
<br />
class DataContainer : IDisposable<br />
{<br />
protected bool m_isDisposed = false;<br />
<br />
public void Dispose()<br />
{<br />
Dispose(true);<br />
GC.SuppressFinalize(this);<br />
}<br />
<br />
~DataContainer()<br />
{
Dispose(false);<br />
}<br />
<br />
protected virtual void Dispose(bool disposing)<br />
{<br />
Console.WriteLine("DataContainer.Dispose: " + disposing);<br />
<br />
if (m_isDisposed)<br />
return;<br />
<br />
if (disposing)<br />
{<br />
}<br />
m_isDisposed = true;<br />
}<br />
}<br />
dev
|
|
|
|
|
A few C# 2008 and C# 2010 the applications were written as console applications. However now I want the programs to compile as windows applications instead. The problem is when I checkout the code from version control software, the default compile option for these programs is as a console application.
Thus is there a way in visual studio 2008 and/or visual studio 2010 to set the default compile option for these programs to be windows applications? If so, can you tell me how to accomplish this goal?
|
|
|
|
|
Do you want to change the app to a windows service or to a winforms app. Both will need some modifications from a console app.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
There is nothing that will automatically convert those to WinForms apps. You WILL have to recode the apps at least minimally to accomplish this conversion. Since we can't see the source code, it's impossible to tell you exactly what you have to do or how much work it's going to be. It really depends on the quality of the original coding job.
|
|
|
|
|
There a number of differences between both types of applications.
A windows application will have a designer that will contain information about the form (and other controls when added itself).
There is an InitializeComponent that generates these controls.
private void InitializeComponent()
{
this.components = new System.ComponentModel.Container();
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.Text = "Form1";
}
The entry point to the apps are different.
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
Thus, you will notice that whether you use Visual Studio or build classes in a text editor and compile via prompt, there will be subtle differences that you need to handle.
So it will be easiest to separate the bulk of the business logic from your console app and put it all in a new windows app that you design new.
|
|
|
|
|
dcof wrote: Thus is there a way in visual studio 2008 and/or visual studio 2010 to set the
default compile option for these programs to be windows applications?
They already are Windows applications. Console apps are still Windows applications.
|
|
|
|
|
Hello all.
I have a very simple/complex question to ask of anyone who as ever worked with/in the dinosaur environment known as ADP. Which ironically probably cuts most of our paychecks =(.
I would LOVE to speak with some one who has experience programming from C# to ADP via (preferably) XML or ADODB (which ADP no longer support).
I've received tons of materials from them and have access to their support staff, however their training materials may as well be written with invisible ink, if it was at least written in Arabic/French/Chinese/German/Greek/... at least I could convert it to English and try to understand how it works.
So in short. PLEASE email/reply if you or anyone you know has even heard of any type of .Net to ADP programming.
The basis of this question comes from an integration request to take data from a .Net environment to a ADP environment.
Thanks for any help you can provide.
|
|
|
|
|
Can anyone think of a good resource for such a task? With 34K online users I cannot be the only one having to do this.
|
|
|
|
|
I'm programming a winform soft that needs some kind of multiple lines.
The problem is: when I make a new line in a label it effects the label down of it.
I need to solve this problem by automatically relocate the down label
|
|
|
|
|
You could handle this programamtically. As the height of the label increased move the other label down.
However, this kind of solution could be error prone.
WPF provides neater layout solutions to solve this problem.
|
|
|
|
|
You could use a TableLayoutPanel with enough rows to hold each of your labels. Set the rows to AutoSize and the labels will move to make room for larger labels above them, automatically.
|
|
|
|
|
Third option; throw them on a Panel , with Dock Style.Top.
|
|
|
|