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
Related
Just wondering if anyone might be able to point me in the right direction here.
user = await App.MobileService.LoginAsync(provider)
this is the line of code in question. The problem is; this works fine on 2/3 test machines (All Windows 10), the dialog is displayed and the program operates as expected. on the third machine however, the dialog does not display. I have wrapped the function in a try catch block and I am catching all exceptions that I then route to a MessageDialog to display on the screen. the messages are never shown, as though the try succeeded, but the function exits on that line exactly and throws no exceptions. I am using MobileServiceAuthenticationProvider.MicrosoftAccount as my provider.
Code redacted to highlight the error, the full code returns a boolean value for success/failure. All traces past the failing line do not appear, so the function is definitely exiting at the specified line.
try
{
//This line fails on a single machine out of three
user = await App.MobileService.LoginAsync(provider)
}
catch(Exception e)
{
//when it fails, this does not trigger, and no traces after this point
//appear until outside the function
MessageDialog msg = new MessageDialog(e.ToString());
await msg.ShowAsync();
}
and just to make things really weird...message dialogs prior to this point in the code work just fine...
I suspect that the security of the machine in question is blocking the login (windows defender), but I really have no idea where to look for this, or even how to test the problem further. Any ideas as to what would prevent this single machine from displaying the Microsoft login window, or ideas on further debugging would be appreciated.
You are not awaiting the response from the Async reply. This means that you will have an ordering and concurrency issue - sometimes it will work, and sometimes it won't and it's all in the timing.
You need:
var user = await client.LoginAsync(provider);
In my Form1_Load event, the code execution stops for no reason the middle of nowhere, and just finishes the loading process at that instance, showing the gui, this is the code and the line where it stops:
Downloadn("https://somelinkhere.com/file.txt","Init.txt");
Application.DoEvents();
List<string> links = new List<string>();
var lines = File.ReadAllLines("Init.txt"); //Code Stops and Gui Shows up after executing this code
links.Add(lines[0].Split('^')[1]);
links.Add(lines[1].Split('^')[1]);
links.Add(lines[2].Split('^')[1]);
links.Add(lines[3].Split('^')[1]);
The debugging process shows no errors, what could i be doing wrong ?
I wonder if an exception is being caught and swallowed somewhere, since by the sounds of it the program doesn't crash it merely skips some code. In Visual Studio, go to Debug\Exceptions, tick all the Thrown boxes and try again. If my suspicion is correct, this will identify the problem.
I am experiencing a weird issue in which my app runs perfectly fine when there is a breakpoint on any of my code lines but gives unexpected results when launched without any breakpoints. Basically I am using a GeoWatcher to get location and then getting weather information of that place. I have also placed Messagebox to verify that my required code executes and it does but doesn't complete the desired functionality it supposed to do. This is the code which needs to be executed for my case but is not executing properly in normal mode.
Dispatcher.BeginInvoke(new Action(() =>
{
IsolatedStorageSettings.ApplicationSettings["CurrentLocationAdded"] = true;
obj.Start();
RetrieveFormatedAddress(obj.Position.Location.Latitude.ToString(), obj.Position.Location.Longitude.ToString());
}));
Kindly if anyone could help me resolve this. I shall be thankful.
Try this :
Dispatcher.BeginInvoke(() =>
{
IsolatedStorageSettings.ApplicationSettings["CurrentLocationAdded"] = true;
obj.Start();
RetrieveFormatedAddress(obj.Position.Location.Latitude.ToString(), obj.Position.Location.Longitude.ToString());
});
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 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.