My wp7 app crashes when I come back from a task such as Map, Call or Web Browser. Infact, if i lock my phone and resume it again, still it crashes. Please tell me what could be the problem and how can I remove it?
There is a problem with you code.
Remove the application off the phone by starting a new emulator instance.
Open App.xaml.cs
Put a breakpoint in the method RootFrame_NavigationFailed and Application_UnhandledException
Now use the CallStack to find the root of the issue.
With no code posted (and in your case it could be ANYTHING in the project) you will be the best person to resolve your issue. If you can post a small reproduction on here we can take a look.
In application exit methods you probably should restore the data you dealt with last time before you quited
Related
I am working on some strange issue with my delphi application.
The scenario is as follows:
If microsoft Lync is running on my machine and if I want to launch my application, it does not getting displayed but the process was started for my application.
and when I close the lync, immediately my application gets visible.
Below are some points which you may need:
My application does not have any link with Microsoft Lync.
Application process is running when I close the lync
Form.Show() is the last statement called from my code.
This issue is not replicated on every machine.
I am not sure why this is happening.
Can anyone help me on this?
Any help or suggestion will be useful for me.
Thanks in advance.
Finally,
After a long checking of the code I came to know that this problem is due to the setting desktop as a parent window somewhere in the code.
Refer this link for SetParent().
When this problem has been discussed with the microsoft I came to know that the Lync is having some issue with some application when we call SetParent(Handle, 0) this will go for a long wait state.
Solution:
What I did is as the SetParentfunction call was important in my code I assign the SetParent property of the form to my application handle so this solves my problem.
The above step is done because in spy++ I found that every delphi application as 2 instances 1 is for TApplication and another is for MainFrom i.e. TForm of the same application.
I have written file picker code in my project. When i run the project in my windows phone by clicking on device button in visual studio, the app runs fine(I mean it opens pictures library and i can select a photo and preview it).
But when I disconnect my usb and then open the app in the phone and when i open pictures library on click of a button , the pictures library opens briefly and then the app crashes immediately(My app closes).
Can anyone please help me with this??
As written in the blog post , the AndContinue method run in a different process and to do so, the current running app goes into the background or even gets closed sometimes, that is what you are experiencing in your app as far i can tell but not sure why different things happening during debug & deploy.
There must be a callback inside app.xaml.cs specifically to handle the condition when calling application(which was sent into background) comes in foreground, read this blog post carefully & you'll understand as what you need to change in your code :
using-the-andcontinue-methods-in-windows-phone
http://blogs.msdn.com/b/wsdevsol/archive/2014/05/08/using-the-andcontinue-methods-in-windows-phone-silverlight-8-1-apps.aspx
I just dealt with this issue and one of the reasons why there are differences between debug and deploy is because of the suspending event.
During debug, the application does not actually get suspended until you manually do it through Lifecycle Events. This means that when you pick a file on debug and the app is put to the background to load the file picker, it is not actually suspended, while when the app is deployed, it actually gets suspended.
Look into your app_resuming method and OnSuspending methods in your app.xaml that may be causing errors not occurring during debug.
I've associated my Windows 8 App with a file type. However when I open that file my app starts to open and then crashes.
I can't figure out a way to do this while the debugger is attached.
I assume there is something wrong with my OnFileActiavted method so I've resorted to changing random bits of code in that method. This isn't working, so I'm wondering how I should debug this problem.
Does this work? You can debug without launching the app immediately. You can also debug other people's apps.
Another approach:
Debugger.Launch();
When your app starts and execution reaches this line, your app will be stopped and VS will ask if you want to attach a debugger.
I'm writing a WP7 (Mango) application.
I store values in WP7 IsolatedStorageSettings.ApplicationSettings, then I call IsolatedStorageSettings.ApplicationSettings.Save();
If I press back, and leave the screen, and I come back I can read values just fine.
However if I press restart in the debugger (or just restart from the emulator) the ApplicationSettings throws a KeyNotFoundException, as if it didn't persist...
I haven't yet tried it on device, I don't have one available right now.
What can I possibly be doing wrong?
It turns out the problem wasn't in the emulator AT ALL, so everyone suggesting this is "by design" in emulator turned out to be wrong (but I can't undo my upvotes as they are locked).
The problem was that I tried to persisting a non-serializable class, and wp7 handled this by throwing away ALL my settings at next Save(). When I removed that single Add() (or more precisely serialzied that object with JSON.net (which COULD handle it), and persisted the json string) all my problems simply went away.
Still, ridiculous behavior on wp7's part.
This behavior is "by design" on emulator.
I suggest, below steps for your code.
1. Check Key is available or not
2. If not, then set default value to it.
Check that question: Automatic login process in Windows Phone 7.1 application
On emulator IsolatedStorage is not persistent after reload and that's for both files and application settings.
You can use Isolated Storage Explorer Tool from wp7 sdk to take a snapshot of isolated storage content and restore it after the restart: Click
That problem doesn't occur on real device where Isolated Storage is persistent.
I got the same error(The error occurs because after you stop the debugger the key get deleted), and I posted a question regards this: Automatic login process in Windows Phone 7.1 application. suggest you to use site settings instead of application settings. One more option:http://www.codeguru.com/csharp/.net/wp7/article.php/c19215/Using-Isolated-Storage-for-your-Windows-Phone-7-WP7-App.htm. Hope it solves your problem.
I have a simple Windows Phone 7 application which is working perfectly when started from Visual Studio. However, if I deactivate the app (press Windows button or back button from the application's MainPage) and then click the app's icon to relaunch, the screen will flash and return to the list/home screen. I assumed this was an issue with the emulator but when I got a developer device I have the same issue.
Note that reactivating without a complete tombstone works (pressing Windows button from the app and then back).
I have no idea what causes this or how to proceed with debugging. Hopefully someone else has experienced this and knows a fix.
Turns out there is a bug, i found the solution here http://forums.create.msdn.com/forums/p/67522/416995.aspx
In short, it turns out that the Microsoft.Xna.Framework.Media.MediaLibrary class (which I am using to display pictures on applications main page) is not properly initialized when the user has not opened a media hub prior to you calling it. So picture collection properties are null or empty. The solution is to add a call to MediaPlayer.Queue.ToString(), it will force the initialization of the native media library allowing you to invoke the MediaLibrary later on.
Sounds like an unhandled error on startup is causing the app to crash.
Trap/log/handle/display any unhandled exceptions. Also check what you're doing on startup.
IF you are saving something (to Isolated Storage) after first run and then opening it on subsequent launches then that's where I'd look first.
If it works when launched from Visual Studio then this will probably be due to the way you are rebuilding/redeploying the app before launching it in that case.