I have a problem with the OpenFileDialog from Windows Forms (it does not matter if I use is in a console application, win forms or wpf) (C#).
I have a small test project with a button that, when pressed, will ask the user to select an image (using OpenFileDialog) and send its path to a process method. The process method is in c++ native code and accessed using c++ cli (CLR). This method send a request to a web service and waits for the response (the web service is local, so the response is fast).
The problem is this: if I press the button 2 times (select an image + processing and after it's finished I process another image), the 3rd time the window will not show, it gets stuck at ShowDialog.
If I run it from WPF it gives me this error:
DisconnectedContext occurred
Message: Managed Debugging Assistant 'DisconnectedContext' has detected a problem in 'd:\Project\WpfApplication1.vshost.exe'.
Additional information: Transition into COM context 0x1b09d5d0 for this RuntimeCallableWrapper failed with the following error: The object invoked has disconnected from its clients. (Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED)). This is typically because the COM context 0x1b09d5d0 where this RuntimeCallableWrapper was created has been disconnected or it is busy doing something else and cannot process the context transition. No proxy will be used to service the request on the COM component and calls will be made to the COM component directly. This may cause corruption or data loss. To avoid this problem, please ensure that all COM contexts/apartments/threads stay alive and are available for context transition, until the application is completely done with the RuntimeCallableWrappers that represents COM components that live inside them.
Any ideas how to solve this or what it means ?
I found the problem (it was not from the webservice communication): Somewhere in my native code I was uninitializing COM, but .NET UI needs COM to be up and running.
So all I had to do is remove the unitialization of COM from my native code.
Related
I am developing an Android App with Xamarin Android.
I'm using the InAppBilling Plugin from James Montemagno.
When I call PurchaseAsync Method the PlayStore dialog opens. But in the background my app freezes and I dont get any result.
var purchase = await CrossInAppBilling.Current.PurchaseAsync(productId, ItemType.Subscription, "apppayload");
In the Sys Log theres a android.app.ServiceConnectionLeaked error:
02-17 22:13:05.434 LENOVO YT3-X50L Error 8031 ActivityThread android.app.ServiceConnectionLeaked: Activity md5742c3bd4cdfedb6330d25c53207d662c.ShopActivity has leaked ServiceConnection md57a6f08dbc6561d468b2675b2ac9edab2.InAppBillingImplementation_InAppBillingServiceConnection#2277a40 that was originally bound here
at android.app.LoadedApk$ServiceDispatcher.<init>(LoadedApk.java:1092)
at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:986)
at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1303)
at android.app.ContextImpl.bindService(ContextImpl.java:1286)
at android.content.ContextWrapper.bindService(ContextWrapper.java:604)
at mono.android.view.View_OnClickListenerImplementor.n_onClick(Native Method)
at mono.android.view.View_OnClickListenerImplementor.onClick(View_OnClickListenerImplementor.java:30)
at android.view.View.performClick(View.java:5205)
at android.view.View$PerformClick.run(View.java:21164)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5417)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:728)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
I only get this error on LENOVO YT3-X50L. On Samsung phones it works fine...
ServiceConnectionLeaked
The CrossInAppBilling code does not take into consideration that your Activity can be killed/flushed from memory due to memory pressure/requirements and does not directly do anything to try to prevent it, it is up the app developer to determine when they need to take special action.
This is something I see a lot of in lower-end Android devices and the the new Android Oreo Go (<=1MB) test devices, but can happen on any device, but mostly noticeable on 2GB and lower devices.
Before calling any external code flush/release as much memory as possible
Focusing on releasing images is usually the largest payoff for memory reduction (restore them after the purchase is completed)
In cases of the Oreo Go 512MB devices I have had to go the extra mile and finish the current Activity, create a new blank/empty transient Activity and then call the external code (app billing, camera, etc) and upon completion, restore the original activity and bring it up to date with the new information externally obtained.
Note: profile your app and the activity first in order to focus your time.
Use your own Keep-Alive Service
Using Start/StopService and not Bind/UnBindService
Make it a Foreground Service
Note: This does not prevent the OS from killing/flushing your Activities/Services, it just provides a "hint" that it should not...
Note: Monitor the Importance state within the RunningAppProcessInfo to determine if your app is entering ReasonServiceInUse before you execute the external code.
I have a situation,I have an application which sends mail using OUTLOOK,problem is while I'm trying to send mails from the application which is opened as Administrator it throws exception
Retrieving the COM class factory for component with CLSID
{0006F03A-0000-0000-C000-000000000046} failed due to the following
error: 80080005 Server execution failed (Exception from HRESULT:
0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
Is there any way to solve it programmatically?
You could call Process.GetProcessesByName() passing in OUTLOOK or whatever the actual process name is.
This gets you an array of process. You can then iterate through each of these and check the user that started the process. If the user isn't the ones you want you can call Process.Kill() and terminate the process.
Getting the user might be tricky, you can use WMI for this (you could also use WMI to list the processes).
Check this answer here for getting the user name.
However I would rethink how you send your mail. The last thing I'd want as a user is watching my Outlook disappear because your application is trying to send an e-mail.
Perhaps a little late to the party on this one but there are two possible approaches here.
As highlighted by Lloyd, you can attempt to connect to an existing Outlook process for the 'current' user (if one exists) by calling
Process.GetProcessByName("OUTLOOK");
This gets an array of Outlook processes and you can iterate through these until the instance you're looking for.
Alternatively, (or if no process is found), you can initialize a new instance of the Outlook application, connect to the default MAPI namespace and send your email that way. Presumably you're using objects defined in the Microsoft.Office.Interop.Outlook library?
You may need to call the Logon/Logoff routines against the namespace and proceed that way, remembering to correctly dispose of any new instances after use, even acquiring the process ID of the new app instance and calling .Kill on that.
I have a compiled WCF-Service (*.exe) with all needed dll's and now I need to create a windows-Service out of this without having the source. Is this possible? If so, how to achieve this? The wcf-service is a console-based-service and the console must not be displayed while the windows-service is running
allready tried with sc.exe, but that ends in following error when I start the windows-service:
"The service MyService could not be started"
Error 1053: The service does not respond on time on the start- or control-request
-> Error-message translated from German
If the program implements the ServiceBase class you can use installutil (http://msdn.microsoft.com/en-us/library/50614e95.aspx) to install the service.
Otherwise you can have a look at srvany (http://support.microsoft.com/kb/137890)
You might run into issues if the service was planned as a console application, because you never know if at some point user input is required or a message box pops up. In this case your application will become unresponsive and it will be very hard to track down the cause.
I have an issue. I'd have a video player that takes in simple parameters as a c# form app. As an experiment to better understand programming, I'd like to have only one instance of the app running and have it refresh with the new args if the open command is given. I could program it so that when it gets the signal, to refreshVideo() or something like that.
Pseudo example:
//app is started from cmd line
//open app for first time
vidViewer.exe("lotr.avi", "44:44");
//keep instance open but have it refresh with new movie
vidViewer.exe("star_wars.avi", "22:32")
As it stands right now a new app with embedded video player will open, so I could have 100 open flicks if I passed it enough args. I'd just like to keep it at one.
Can provide more info if needed.
Thanks all,
Kevin
My suggestion would be to design your application such that, when launched, it would attempt to acquire a system resource that is mutually exclusive (meaning that only the first instance would succeed). Since, in your scenario, you will also require a means of interprocess communication (to transmit the name and start-time of new videos), you may use the same mechanism for achieving this.
You could, for example, use a self-hosted WCF service, bound to a fixed TCP port, that each application instance attempts to register upon being started. Due to the way ports work, only the first instance will succeed; subsequent instances would fail with a “port already in use” exception.
If an instance manages to register the WCF service, then you may assume it to be the “principal” instance and proceed to play the video on it. It should, however, listen for incoming messages from the WCF service and update the video being played accordingly (see below).
If an instance finds that the port is already in use, it should assume that another instance is already running. It would then initialize a WCF client that sends the name and start-time of the new video to be played to the WCF service. Finally, it should terminate itself without displaying any window, assuming that the principal instance will take care of playing its video.
currently I’m creating 2 applications (app A and B) for Windows Mobile 5.0 and using Compact Framework 2.0. App A is the main application and B is the sub application.
Below is the flow:
Start app A.
App A will start app B.
App B will do some process.
App B will kill app A.
App B will patch/upgrade app A. (ala update manager)
App B will restart app A.
App B will exit.
Now I’m stuck in killing app A. I did tried using OpenNETCF ProcessEntry Kill() function. When calling Kill(), it made the device crash.
I did tried using the SendMessage(hWnd, WM_CLOSE, 0, 0) funct where WM_CLOSE will have the ProcessEntry.ProcessID value and I didn’t assigned any value to hWnd variable. But it didn’t terminate app A. Did I assign the wrong value?
I also did tried using
Process.GetProcessById(processEntry.ProcessID).CloseMainWindow()
, but failed as GetProcessById only accepts int32 value. Note that processEntry.ProcessID value is larger than int32 value and GetProcessByName() is not supported in Compact Framework.
Could you help me in killing app A through app B?
Thanks.
You may try native code, using the TerminateProcess function:
processHandle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, Pid);
success = TerminateProcess(processHandle, 0);
The above code is from a Task Manager at Code Project.
However if you are writing the code for both the applications, it will be better if you designed a communication mechanism between the two applications. In this way you will send a message from app B to app A and app A will kill itself.
Stormenet, I hardcoded the application's name. Then I generate an object to get all the available process using OpenNETCF.ToolHelp.ProcessEntry[ ] = ProcessEntry.GetProcesses();
then in a foreach loop, if the ProcessEntry object eg: processEntry.ExeFile matches with the "applicationName", i shall use processEntry.Kill().
I think you can get the OpenNETCF.ToolHelp dll from the OpenNETCF site.
Note that if the application you are trying to kill is holding open ports or other system resources then it might hang on exiting. Ensure everything is effectively disposed when the form closes.
This can be acheived by putting stuff in the:
public void Dispose(bool disposing)
{
}
block of code in the designer of your main form, or if you've chosen a less Windows Form centric architecture then just run your dispose calls following Application.Run(new YourForm()) and it will execute after the application has closed.
If you're feeling really lazy then just setup some destructors (otherwise known as finalizers ~) but be careful about navigating through relationships between managed objects at "destruct" time if you do this as there is no guarantee as to which order objects will be destroyed.
ctacke, I think app A crashes due to some of the running threads are not closed properly or still running at the background as app A will run multiple threads during app B executing the Kill( ) function.
If I use the SendMessage(hWnd, WM_CLOSE, 0, 0) function, it will not crash the device (which is a good thing)... it only closes the form. (app A contains multiple forms eg: frmLogin and frmMainMenu). hmmm maybe I need to point hWnd to the right form...
Now I'm taking a different route.
After downloading the patch and put it in a temp folder, I'll do a soft reset using OpenNETCF.WindowsCE.PowerManagement.SoftReset().
App B will be launched upon startup, then it will scan the temp folder and replace app A with the new version.