I have the following code in a C# windows form application.
if (myGrid.Rows.Count != 0)
{
// do something
}
else
{
MessageBox.Show("Test");
}
The message box shows up in Debug mode but not in release mode. Any idea why?
I am having similar issues with other code as well
For instance
if (!myParameter)
this.mycheckBox.Enabled = false;
else
this.mycheckBox.Enabled = true;
The above code works in debug mode not in release. Not sure why.
Thanks
In release mode myGrid.Rows.Count != 0 must be true, try putting another MessageBox.Show there.
Probably because your if statement is true in release mode.
Remove the if and keep the MessageBox.Show("Test"); and that should work just fine
EDIT
You can even go a step further by putting a breakpoint at the if statement and seeing what value is being returned. This would work for both sections of code.
Try putting messageboxes or breakpoints before all your if statements. What is the value of the parameter you are about to test?
If this does not shed any light, make a new, empty winForms project, and put in a messagebox with no conditions. If that works, start adding your old code to it piece by piece and watch to see where it breaks.
Related
A strange behavior is occuring when running my application.
If I stop the code in debug mode before a specific line is reached, that line will be executed and everything is normal... but if i let the code run without debugging, of stop the code after, it will not run the line...
This is the code
if (SelectedProducts == null)
{
Global_Image.Product_Types = null;
Global_Image.Product_Types = new List<Prod_Product_Type>();
return;
}
I'm trying to make Global_Image.Product_Types count go to 0 by making the List null and creating a new list for it... but if I stop the code in the return none of them worked... If I stop before, they run and it works fine... can someone explain this behavior?
The function is not awaited, so no sync problem here, I think... The App is in azurewebsites...
please help
My automated tests used to run smoothly, but we moved the QA environment to a different server, and now the tests are failing because the it keeps tries to click on elements that are still loading and greyed out/disabled. Here is part of the code that worked just fine on the previous server:
while ( less than 7 seconds )
if (driver.FindElements(by).Count > 0)
{
if (driver.FindElement(by).Enabled && driver.FindElement(by).Displayed)
break;
}
else
{ go back to while loop }
The problem is that driver.FindElement(by).Enabled keeps evaluating to 'true' (I found out during debugging) when the page is clearly still loading and the entire page is still greyed out, causing the driver to proceed to try to click on the greyed out element, and then of course the test fails with an exception. Has anyone encountered this kind of issue? I use Webdriver with C# and NUnit, run test in IE. Thanks.
The Enabled method only works for Input elements and radio buttons. For non Input elements use GetAttribute("disabled"). This will return "true" if disabled="disabled", or null if still enabled.
Pretty old question but I will still respond just in case. The answer is right here in the help of IWebElement.Enabled. It quotes
The Enabled property will generally return true for everything except
explicitly disabled input elements.
I am working on an app that uses location services. If I am debugging, the app works fine. If I start without debugging, on the first run (after rebuild), it crashes when asking for authorization to use location services. What happens is that if you let it sit, with the messagebox showing long enough (5-10 seconds), it crashes. If I start without debugging again, it works fine (though it doesn't show the messagebox again, because somehow it gets past that line to the next line AFTER the conditional statement, where it sets first run false (I assume, because it doesn't show again).
Again, if I am debugging, no problems. If I start without debugging, it dies. This is the case when building in either the Debug or Release modes.
If I comment this block of code out, it executes without a problem. If I click OK quickly, it executes without a problem.
if (settings.FirstRunLocationPermission)
{
string message = "Do you wish to use location services to see your location on the map? Your location is not being tracked. You can change this authorization in the settings.";
//if (MessageBox.Show(message,"authorization",MessageBoxButton.OKCancel) == MessageBoxResult.OK)
//{
// settings.AllowLocation = true;
//}
settings.FirstRunLocationPermission = false;
}
I would greatly appreciate it if anyone can explain to me why a simple messagebox checking for ok would cause a problem like this. Thanks!
Most likely you are showing the MessageBox in OnNavigatedTo. If that is the case, this SO answer should help. The problem is that if the user does not press a button your app will crash since the framework thinks that navigation has failed.
And yes, this behaviour occurs to me only when debugger is not attached.
If you look at the MSDN Documentation for the method, the reasons for the possible Exceptions is fairly clear:
MDSN - MessageBox.Show Method
The other possibility is that there is some code running in the setter for the settings.AllowLocation property that is throwing the Exception. It would help if you included the actual Exception being thrown.
I use it this way, and it works :
var msg = MessageBox.Show("Do you .... ?", "Title", MessageBoxButton.OKCancel);
if(msg == MessageBoxResult.OK)
{
//Do something;
}
Good luck
I have an if/else statement that is not working.
while (rdr.Read())
{
string permission = rdr["Permission"].ToString();
if (permission == "Exec")
{
Run my code
}
else
{
lblErrorStart.Visible = true;
}
}
If Permission does equal Exec then everything works fine but (when stepping through the code) I have noticed that when Permission does not equal Exec, it does not trigger the Else. It just goes back to the while statement and stops. Let me know if I need to provide any more code.
Note: I only have Exec in the database. Everything else is null.
I have noticed that when Permission does not equal Exec, it does not trigger the Else.
I have a very hard time believing that. Please show us the exact contents of permission when it does not equal "Exec".
Also realize that setting the label to visible will not update as soon as that code is executed. This is because you are not allowing the Windows Message Loop to process messages. So even though the Visible property is set to true, a WM_PAINT message is never processed (until your loop exits), so the appearance of your control will not change.
EDIT:
As Brian Gideon points out in a comment, your executable version may be out of sync with your code. Rebuild the entire project and try it again.
Sometimes when testing exact equality, you fail based on what you do NOT see... If your data is from a record set, or other structure and the actual value is NOT trimmed(), it will fail...
"Exec " == "Exec" will fail
Try
string permission = rdr["Permission"].ToString().Trim();
Basically it's an if else statement like stated:
if(label1.Text == "True")
{
label1.Forecolor = Color.Green;
}
else
{
label1.Text = "ERROR!";
label1.Forecolor = Color.Red;
}
Also, you can do multiple if statements and if none of them are relatively true you can have them all lead to the else statement.
In my application I have a lot of Console#WriteLine or Console#Write calls. This are so many, that the application is really slower than necessary.
So I'm looking for an easy way to remove or at least disable all Console#WriteLine and Console#Write calls.
What's the easiest way to achieve that?
Here's a even quicker quick fix I implemented.
...
static int Main(String[] args)
{
...
#if !DEBUG
Console.SetOut(TextWriter.Null);
Console.SetError(TextWriter.Null);
#endif
...
}
HTH
Maybe Find&Replace function in any code editor?
For example find all
Console.WriteLine
and replace with
//Console.WriteLine
To switch off Console.WriteLine() output in runtime temporarily use
// backup the previous output handler connected to Console
TextWriter backupOut = Console.Out;
// activate a null handle
Console.SetOut(TextWriter.Null);
// this console output will be invisible
Console.WriteLine("Hidden output on Console.");
// restore the previous handle
Console.SetOut(backupOut);
// this console output will be visible
Console.WriteLine("Showing output on Console.");
Similarly, you can disable program Debug.WriteLine() output in runtime, also while compiling in Debug mode, by using a dummy TextWriterTraceListener, like so
using System.Diagnostics;
using System.IO;
//...
public class MyDummyListener: TextWriterTraceListener
{ }
// ......
[STAThread]
static void Main()
{
// Back up the old one
DefaultTraceListener[] debuglisteners = {(DefaultTraceListener) Debug.Listeners[0]};
// Plug in dummy listener
TextWriterTraceListener[] dummylisteners = {new MyDummyListener()};
Debug.Listeners.Clear();
Debug.Listeners.AddRange(dummylisteners);
// this is an invisible debug message
Debug.WriteLine("This one is invisible");
// ..
// to activate output again, plug in the previous listener
Debug.Listeners.Clear();
Debug.Listeners.AddRange(debuglisteners);
Debug.WriteLine("This one is visible again");
// ....
}
Note: I tested above code in .NET Framework 4.7.2 in Debug mode, using the Winforms platform.
If they are non-essential (logging) then you should have used System.Diagnostics.Debug.Print() to start with.
Luckily WriteLine() is compatible with Debug.Print() so that's an easy S&R. And fix some usings maybe.
Replacing Console.Write() might be a little trickier.
To be complete: The Debug.Print() statements can be turned on/off with a checkbox in project|Properties.
Use a simple, non regex, Find/Replace dialog, and replace every Console.WriteLine( by Debug.WriteLine(.
You can then keep the possibility to track what was previously outputted directly to the console window, still optimizing performance in release mode.
In Visual Studio, use the Tools|Macros|Record temporary macro option to record a macro that does a Find of "Console.Write", and deletes the line. That is:
Ctrl+F to find "Console.Write"
then Ctrl+L to delete the line.
Save the macro and then run it against every file in the project that has the offending lines.
Should take about two minutes.
I would suggest, however, that you back up your source first. Just in case.