Windows forms application should be started multiple times when user clicks on the button inside the main form and he/she should be able to switch between running instances from application menu. Applications should be isolated from each other, so static classes and libraries should not be shared between instances.
One apparent way is to use separate processes, but it will be too heavy, may be I should use application domains,but there is no such sample in the net.
Can anyone suggest the best solution for this problem ?
Related
I'm new in programming with .Net and C# and, as said in the title, I have a WPF app which is accessible in a system tray icon and I want to run it a windows service.
Typically, I want an output like it was described in an answer provided in a discussion here.
If you want it in the system tray I think what you'll have to do is make it a Windows service. I've only written 1 Windows Service and that was years ago, but I believe that's what you'll have to do. If I'm correct about writing a Windows service, then what I would suggest you do is create a new Visual Studio solution and add two projects to it. One would be a DLL which would run as a Windows service. The second project would be a WPF project that will be your UI the user interacts with. Then you'll have to use some messaging system to communicate between the two. For the action messages that would mimic what Outlook does, I've used some WPF toast messages to accomplish that. If you Bing/Google "WPF toast popup" you'll get lots of results.
I have many searched in Internet and find some helpful answers like:
URL1
You can't, not directly, because the windows service will necessarily start when the machine does, not when a user logs in. The service will also be running in a different context, likely as a different user. What you can do is to write a separate system tray based "controller" that interacts with the service.
URL2
It needs some effort to achieve. Well, just two hints: 1) use static property System.Environment.UserInteractive to detect in which mode your application is running, see http://msdn.microsoft.com/en-us/library/system.environment.userinteractive.aspx; 2) get rid of app.xaml, because it will force starting WPF Application in all cases; instead, create and run and instance of System.Windows.Application (or better, a specially derived class) explicitly and only for interactive mode, see http://msdn.microsoft.com/en-us/library/system.windows.application.aspx.
And, I could not apply their instructions.
Thanks advance!
I've got an issue with the focus management in WinRT. The issue is specific for the application startup. Let me share the example of it:
If during the startup I change the focus (for instance I can start selecting some text in a browser), the runtime will decide that it doesn't need to show the application. The application is being started in a 'hidden mode'. It means that I do not see the UI, but I still can find it in process explorer.
So what I need here is to make the application be active in all possible cases. I tried to use several native functions such as ShowWindow, SetActiveWindow, SetForegroundWindow, but without any success.
I also noticed that any WinRT app is being started under WWAHOST.exe and mainwindowhandle is 0. The app shows up if I use 'Switch to' option in Process Explorer context menu.
WinRT applications are sandboxed and have very little control on the way the OS handles them, and almost no way to affect the behavior of other applications running on the same host. What I would suggest then is for you to design your application in such a way that it shows some UI as early as possible, then asynchronously you can load any other resources that your application may need.
I've created a simple application that I wish to be a process and not show up as an application inside taskmanager, simply because it is not an application. It was intended to be a process.
You might want to read about Windows Services.
Walkthrough: Creating a Windows Service Application in the Component Designer
Creating a C# Service Step-by-Step: Lesson I
You don't give much information about what you application does, but either Console or Forms will be displayed on the TaskManager, and even as a process it will be shown over the Processes tab so I'm not sure what are your intentions with this.
We have a legacy software which was built in MS-Access (UI) but was using Sqlserver 2005 as database server.
The UI in Ms-Access has got Menus with different menu-items. But some of the menu-items doesn't have screens yet (incomplete). So we decided now to move to .net environment (i.e. .net web application). Here is my main question.
Firstly I want start working on the screens in .net (.net web application) which are incomplete for the menu-items in MS-Access. Secondly I will be completing the other screens which are now working in MS-Access UI. So how can I use/call .net web application screens when ever user clicks on menu-items in MS-Access UI.
Please suggest me.
Thanks
It not really practical to integrate screens built in Access with some web based forms. I not sure why or who or what was suggested to you that such an approach is EVER used in our industry.
You can most certainly launch any web form or web site or launch any URL form the Access client running on your desktop. The code to launch that URL is:
Application.FollowHyperlink "path to web form or site goes here"
So you can place a button or menu in an Access form to launch a web form, or even launch eBay if you want. However I do not think the issue (or solution) is the ability to launch some web form, but is having parts of the application talk to each other.
An application becomes useful since all the application parts can tightly talk to each other. Access is a great RAD tool due to great ease as to one form launching a report or another form and passing information. And all of that application can EASY share common code and routines that allows you to accomplish useful business tasks.
So when you click on a detail row in an Access grid of data (continues form), then launching another form to edit the one record takes one line of code. So an application is never really just a single standalone form to edit data, but the talking between the forms and use of code and how those objects dance together is what really makes an application useful. If an application was just forms with no code then I think we would be all out of job in this industry.
The model of how you navigate and build web applications is rather different then how Access works. I mean if you have 5 browsers open, which browser has some form to edit your data and which browser is watching videos on YouTube?
You really cannot approach such a half-baked system in which some forms are in Access and parts of the application are web, based. The only way this is practical is if the web forms do not need to work with or use any of the code in the client forms.
However, you CAN build web forms in Access 2010. In other words, in the Access client you can build both client forms and web forms. The client forms can call and use web forms (they run in the client) as regular forms and things like where clauses etc. will work). When you publish to the web, then ONLY the web forms run. Here is a video of an access application of mine, and note how at the half way point I run the same forms in a web browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
However, the above ability in Access right now cannot work with sql server, and must use SharePoint (or the upcoming office 365).
So no question the concept of moving bits and parts out of an application to being web based makes sense (so your concept of not moving ALL of the applicaton out to the web makes sense). However, the parts being moved out to the web must make sense as web or stand alone and not require integration with the client forms (at least during use).
In other words if you have a legacy payroll system in Access now, but want employees to enter their payroll hours, then that new web part is separate from the payroll system. And no question the payroll system could take and pull hours from the new employee hour entry system that is web based.
However, the idea that menus and parts of the client based application will seamlessly launch and use the web browser parts makes no sense at all . Again this makes zero sense and you are barking up the wrong tree here. As noted, if the web part is really a separate business process, then there are some possibilities here.
Last but not least, you can certainly build a set of web services (application business code and logic that is separate from the UI) on the .net web site. This separate business layer could then be used by both the Access client forms and the web forms. However, once again such a setup likely suggests that you better off to build the application as web based anyway as the web based forms can talk and use the business code with greater ease then the client forms can – only exception here again is if you using Access web services, then both web or client forms can use the stored procedures and business routines you write to run server side.
Last but not least, perhaps your problem(s) are solved by increased connectivity, and not really the need for web based? I address this question in the following article of mine.
http://www.kallal.ca/Toweb/Index.html
I am (still) writing a small application which requires me to use several windows forms to show to the user.
Some of the forms just show progress messages while the application performs tests using several external devices.
The forms will usually be used in order (see below) but there may be some errors picked up from the devices, in which case an Error Reporting form will be used. The user will have the option to go back to the beginning or to the 2nd test (the 1st test takes 30 mins to perform). The error report can be invoked from any other form.
Also, the final form has the option to go back to the beginning to perform the tests on a new device.
Obviously this would cause the suite of forms to get rather tangled up. if it were used for several devices with errors etc.
So am I have a few questions.
Am I using the forms correctly and if so, how do I pass control from one form to the next one without having to go back to the original form, if that makes sense ?
Can I still have access to all variables created in preceding forms, or should I create all the variables in the initial form setup ?
Or should I have all the processing within one parent form and simply "show" the other forms as part of the procedure ?
I hope this doesn't sound too stupid, but I havent used multiple forms in C# yet. The steps are ALSO dependent on each other.
The following is the usual flowchart of forms, with PRGERREP being called from any form (more or less).
PRGSTART
PRGDEFAULT
PRGTEST1
PRGTEST2
PRGTEST3
PRGTEST4
PRGMANUAL
PRGFINALE
PRGERREP
Any help or advice would be most appreciated.
Please try to focus more on the question, not the context.
Even though i don't know exactly what you want, you should check out MDI Applications.
Basically you have a parent form with several child forms. Should your tests be finished you can BringToFront() the corresponding child window from the parent form.
I question the requirement to use multiple forms for this. Most applications show all information for a task; progress, tests, errors, messages, et al. in a single window, not multiple windows. Web browsers and office applications are very complex programs and manage to show all task information in a single window.
The fact that you are trying to "pass control" between multiple forms makes me suspect using multiple windows is a bad design. Look at the windows on your screen now; each one is a self-contained environment and does not need to "pass control" between each other.
If you are trying to make the user do something in sequence, handling errors before going on to the next step and allowing the user to "go back to the beginning", a wizard-like design may be better.
Create a single form with fields and buttons for the first task. Clicking a button redraws the form with fields and buttons for the next task, and buttons to go back or start over. This can be done more easily than creating a bunch of separate forms and trying to synchronize data between them.
Consider inheriting from an ApplicationContext to implement this logic in your application. See here and here.