Is there a way in CF to see which process uses a certain file?
I have an SDF which I want to delete and then overwrite it with another sdf. File.Delete throws an IOException saying file is in use.
I am sure I have closed all DB connections.
AFAIK there is no way to find which process locks a file on WinCE or Windows Mobile.
You should double check if all open connections and references to the sdf files are closed from your code.
As a workaround write another 'updater' app. Then close your main app and start the updater app to replace the sdf file. The updater then could start the main app after the update. You may use named events to sync this: Start new process and wait for 'process started' named event. Then close main app. After update start main app and wait for a named event which states that main app has started, then close updater app.
Related
Situation:
I have a 3rd party app that does not accept its files in parameters during exec. The only way is to open a file through FILE/Open menu or by dragging and dropping a file onto the app's form.
I want to create an app in vb.net that will handle this file as its own, then lunch the original app and initiate the drop of file.
Question:
How can I drop a file/file path onto 3rd party's app from code?
I imagine I have to find the app handle and send some drop event with a path to file?
I am trying to get my application to launch an MPG file in whatever application the user has set as their default player. I can do this by using:
Dim movie as Process = Process.Start("movie.mpg")
However I also need to know when the user has finished watching the video and has closed the default player application. For this I would normally use movie.HasExited but this returns Object reference not set to instance of object
I'm guessing the cause is that vb does not know what process was launched by windows as a result of opening an MPG file?
If so, how can I get my application to open the default (user defined) media player and still control the process?
Thanks
I have created a custom file type that is recognized by my application, and I would like to know what event is triggered when I open my application by double-clicking a file of this type. I have placed breakpoints at the beginning of handlers for Form.Shown and Form.Load, as well as at the beginning of the form's constructor, but the application never hits the breakpoints.
If you're opening the application by double-clicking on the file in your computer's filesystem the debugger built in to Visual Studio won't be attached to the application's process and so won't break at your breakpoints. You can attach the debugger to a running process, but what you're talking about happens fairly quickly, so you will almost certainly not be able to attach to the process fast enough to set your breakpoints and catch the execution as it passes them.
Ultimately, the events triggered when you open your application via a file association is no different to opening the application by running its executable file.
For using that file :
Just get your file from commandline args and process it on which event you want. My.Application.CommandLineArgs
After this if you want to debug:
You can put that arguments inside Properties-Debug- Start Options -Commandline arguments (argument will be your file)
and put breakpoint on the event where you were processing that file
Happy debuggings
If you're creating your program as a Single Instance Application, then you'll receive the Startup event for your first instance, and the StartupNextInstance event for each subsequent invocation.
Each of these events hangs off of My.Application and provides the command line parameters that were passed to each invocation.
If you're not using a Single Instance Application, the Startup event is still available.
I want to be able to restart the app when coming back from background. So if the user selects the app again it should start as if it were the first time it's open. I've been googling but couldn't find a way of doing this.
I was thinking in just add the main view of the app in applicationWillEnterForeground, but It would be great if I can deallocate resources.
You can't restart an app. What you can do is disable background support, so your app always completely terminates when closing.
"...you can explicitly opt out of the
background execution model by adding
the UIApplicationExitsOnSuspend key to
your application’s Info.plist file and
setting its value to YES."
Source: Opting Out of Background Execution.
I have a Windows program that has a GUI which also uses a command line interface (a cmd Window) as a debugging console. Basically, when it is double clicked, it launches a command line window and then the program creates all the GUI windows. Then you'd have two Windows: the main GUI and a debugging console.
I'm trying to port this pogram to OS X. Because OS X (and all Unix OSs for that matter) doesn't automatically launch a command line window when you run a command line application. So, I obviously need another way to port this application.
My initial thought was simply to import the source code into a XCode project, redirect standard input and output and then port the GUI. The GUI and console would run side by side just like in Windows. I don't think this is the most optimal solution since that would mean I'd essentially have to write a terminal emulator.
My other thought would be to port the application as a command line application which creates its GUI just like in Windows. The application would then have to be run from Terminal.app which could handle all the I/O. Unfortunately, I don't think you can use the Cocoa framework without using a NSApplication loop.
Any ideas how I could approach this?
You can of course create a run loop from a terminal-launched app. But that generally isn't what you want to do.
It sounds like on Windows, the CLI is just being used as a shortcut to creating a real debugging console window. So the simplest answer is to create a debugging console window. It's pretty easy to create a window which contains just a multi-line text or list view. (If you want something fancier, consider borrowing code from iTerm2 or other open source projects instead of trying to build a complete terminal.) If your debug information is being printed with some fancy macros, just change the macros to log to your list view.
If you're directly doing something like fprintf or syslog to do your logging, it might be simpler to create a wrapper app that launches the main app, and the wrapper creates the debugging console window and displays the main app's stdout and/or stderr. (This might be as simple as using popen.)