|
The trick is to NOT do it. There is no way to change the screen resolution without affecting the desktop, unless you want to write all your window code using DirectX (Don't even think about it!)
You shouldn't be changing the display resolution anyway. Changing system-wide settings is extremely poor practice, considering your sharing the system with other applications. What you do in your application may affect the operation of other apps. Besides, when your app crashes (don't tell me it won't!), how is it going to set the resolution back to what it was?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Strongly agree with you.
This posting is provided "AS IS" with no warranties, and confers no rights.
Alex Korchemniy
|
|
|
|
|
Is there any suggestion on how to make the program portable through different resolution settings without letting the user know?
|
|
|
|
|
To get your application to support multiple screen sizes you need to utilize Docking and Anchor features. 
Of course there's a lot more to it... but this is the start.
This posting is provided "AS IS" with no warranties, and confers no rights.
Alex Korchemniy
|
|
|
|
|
Does anybody know how to create an automation server in C#? I only know how in MFC, but could not find any articles or sample code in C#. All I am looking for is to have my .net application to be launched by another desktop application. Any suggestions would be appreciated.
|
|
|
|
|
Given the wording of your sentance, I take it you mean an automation server as an EXE.
Before starting down that long and winding road, be sure to first read about proper exposition of .NET components to COM by reading Exposing .NET Framework Components to COM[^], Marshaling Data with COM Interop[^], and Nick's Exposing .NET Components to COM[^], which covers a few caveats that the SDK docs didn't mention originally - basically about following COM guidelines:- Always attributes classes and interfaces with static GUIDs using the
GuidAttribute - Never change CLSIDs or IIDs for a particular version of an interface
- Never change the definition of a published interfaces; derive a new version from the old and implement that interface as the first interface on the class
- Et cetera...
To create an automation server, however, takes a lot more work. If you want only a single-instance automation server, there's a lot to do, including interop'ing moniker APIs and interfaces, as well as making use of the ROT (Running Object Table) to register your single instance (the moniker is to respond to access requests to the ROT item that represents your application). If you've done this natively, you've got a good start. Now you just need to P/Invoke the native APIs necessary and declare the managed version of interfaces (don't forget their IIDs for their GuidAttribute, as well as the ComImportAttribute that allows the CLR to marshal from COM to .NET and back again). Depending on the derivation of the interfaces, methods have to be declared in order and with the right DispIdAttribute values.
If you want the easy way, then instead of registering into the InProcServer32 registry key, you need to register into the LocalServer32 key. You can do this and still support registration using the regasm.exe tool but attributing a couple of static methods with the ComRegisterFunctionAttribute and ComUnregisterFunctionAttribute. Use the Microsoft.Win32.Registry and RegistryKey classes defined in the .NET BCL (may not - and probably not - available in other CLI implementations' class libraries) to get the CLSID for your attributed class (or hard-code them, since CLSIDs should never change anyway) and register the path to your executable (not to the mscoree.dll shim like COM servers of the DLL variety do).
You should also support the /automation command-line argument in your Main entry point and enable any automation facilities if necessary. At least eat the switch and don't report an error (and/or quit).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Heath,
Thanks,it is very helpful! Besides automation server, are there other ways to have the .net application (exe) to be called by other applications? What do I need to do in order to add the .net exe as a reference in other .net application? Does the exe has to support automation server (with .tlb file) to be included in the reference? Otherwise, I could create a dll in C# that calls the .net exe and have all other applications to call through the dll. Basically, I use the dll as the bridge between the .net exe and other external applications. Is there any sample code on automation server in C# or VB.net? Thanks again.
|
|
|
|
|
VS.NET can't reference EXE assemblies, but you can if you use the command-line compiler (VS.NET is trying to avoid circular references).
You really need to define "to be called by other applications". That's easy. Just invoke the executable. You can use CreateProcess or CreateProcessEx in native code, you can use WshShell.Exec in Windows Script (VBScript, JScript, WSH, WSC, etc.), exec in Perl, etc. All that without automation. You only need to support automation when you want to automate with that application, but there's still other ways to do that: anonymous pipes, named pipes, DDE (archaic, but still supported), and much more.
And how you use "call" is ambiquous. So what if you create a DLL in C#? Do you simply use Process.Start to run it? How then will you interact with it? You could use .NET Remoting (preferred between managed applications) but then you need to develop a protocol for other apps to tell your DLL assembly what to do. Too much complexity.
That wouldn't easily work anyway. Native applications can't simply load your managed DLL into memory. You need to expose that to COM and then COM clients load a shim (mscoree.dll, or a custom shim like Office 2003 apps use) whichs hosts the AppDomain and marshals calls to your .NET components.
Please be clear on your requirements. If all you need to do is start the application than just use one of the methods I mentioned above. No complexity is necessary.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Not just starting the application, I want other applications to call all functions exposed by the application, just like automation server in MFC. Like Excel, the external application can launch Excel, populate data, and perform any tasks that Excel exposed. I wonder why .net does not have an option or tool to support Automation Server as MFC does. Has the automation server (or out-of-process COM server) been replaced by the .net remoting? In another word, can the .net remoting accomplish most of the tasks that the automation server can? From Nick's code, it seems pretty easy to use a .net DLL in MFC. What do I need to do to use a .net Exe as an out-of-process COM server? Thanks again for your response.
|
|
|
|
|
MFC is still native, just native class wrappers for native Win32 APIs. All the COM interfaces necessary are already declared in other headers.
.NET, on the other hand, uses a completely different runtime that works with COM. Some native COM interfaces are re-declared in .NET, but only what is necessary. Anything else is left up to you.
So, it's not that MFC defined all the necessary interfaces - it didn't - but that MFC was native and the COM headers, libs, etc. were native so they went hand in hand.
You really should read about OLE and COM automation before starting such a project. There's a lot of fundamental concepts you need to understand, and COM is a very difficult things to understand (especially the automation interfaces that you would need to use).
Nick's article is not about using a .NET DLL in MFC. That's not even possible unless you're hosting your own AppDomain (this is documented in the .NET Framework SDK as well, under Hosting the Common Language Runtime[^].It's about exposing an assembly as a COM server that MFC can use like any COM server (no matter in what language it was written). As I mentioned before, in this case the default shim registered by regasm.exe - mscoree.dll - is actually loaded into process memory and it hosts the CLR and marshals calls to the .NET assembly (at this point, in what language the assembly was written is moot - all managed languages targeting the CLR compile to IL - that's the point of the Common Language Infrastructure (CLI) on what the .NET Framework (Microsoft's brand) is based).
Read through the documentation at http://msdn.microsoft.com/library/en-us/automat/htm/autoportal_7l45.asp[^] for a better understand of OLE and COM automation.
As far as .NET Remoting goes, you need to weigh your options. So you want to host a managed COM control in MFC that marshals calls across application boundaries to another application? You do realize what's involved, don't you?
First you're marshaling from unmanaged to managed code (and later, back again). Performance hit. Then you're marshaling serializable data (and you have to declare it using the SerializableAttribute and, optionally, implementing the ISerializable interface or using an ISerializationSurrogate implementation with a custom SerializationBinder across TCP ports (the fastest without defining your own custom remoting channels, until .NET 2.0 comes out with an IcpChannel implementation for IPC through named pipes). Then all that repeats in reverse to marshal data back.
And .NET Remoting is a difficult topic, too. Read Accessing Objects in other Application Domains[^] in the .NET Framework SDK for more information.
There's no easy way, and I'm not trying to discourage you, but you really need to read about your options.
The other way is to P/Invoke the necessary native APIs in your managed code and use named pipes to implement a client/server application, which is pretty straight forward.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thanks for the info. I think I find the solution. I've just created a simple .Net Remoting server(which is kind of new to me) and a .Net client. It seems to work nicely as expected. I then created another simple MFC application using managed extensions to simply delegate all calls to the .Net Remoting server. All the non-managed applications can call via the MFC application. I run through a quick test and it seems to work great. I have not yet to test using Process.Start to launch the server if the server is not running, but it should work. One caveat, if I want to use any COM dlls in the .Net Remoting server, the COM dlls must be dual interfaced automation objects (inherit from IDispatch not IUnknown), or I'll get a "QueryInterface failed" error, which seems make sense. I appreciate any suggestions or comments you may have. Thanks again for your help.
|
|
|
|
|
QueryInterface is a method of IUnknown - not IDispatch - so I don't see what could be the problem. More information may be helpful.
For example - have you created an RCW (runtime callable wrapper) or are you trying to create an automation object? Automation objects - i.e., objects that are late-bound - require either dual or IDispatch inheritence in order to invoke methods at runtime.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Sorry, I replied to myself. Please see my last response. Thanks.
|
|
|
|
|
As a test, I had two COM objects: one is inherit from IDispatch and the other is from IUnKnown. The .Net Remoting server can call any functions exposed by these two objects without any error. When a .Net client call the server to access any functions exposed by the IUnknown COM object, it gives "QueryInterface failed" error, but OK for the IDispatch COM object. I am not sure why it needs to call QueryInterface.
|
|
|
|
|
Jason Ruan wrote:
I am not sure why it needs to call QueryInterface.
All methods exposed by IUnknown - which every interface inherits from - is essential to COM. QueryInterface (or just "QI" for us COM-heads, like you QI for an interface) is how you get a reference to an object based on an interface it exposes, or you get E_NOTIMPLEMENTED if it doesn't support that interface. When an interface is attributed with the ComImportAttribute, the CLR will QI for that interface using the compiler-generated GUID or the GUID in the GuidAttribute for that interface when you cast an object to that interface.
Do the clients make calls directly on the COM object through the remoting proxy, or does the remoting object proxy calls to the COM object? If the clients make calls directly on the COM object through the remoting proxy then the client need a reference to the interface, either defined in the client assemblies or exposed in a shared assembly (unlike managed interfaces, you can define interface with the ComImportAttribute how every many times you want, so long as you use it only to communicate with the COM object, not passing the interface itself since the Type must be the same).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Is there a reason for the .NET Framework installation (versions 1.1 or 2.0) to ask for the machine to restart after the installation?
I want to distribute an application (smart client) and I don't know if the customer machine runs the .NET Framework. So I want the customer to run a URL. This will check if the machine has the .NET Framework. If it has then only the application will be installed. If not then the .NET Framework will be installed first and then the application.
I know that there is an Updater application block and in .NET 2.0 the click once support this feature. The "how to install?" is not the point.
The thing that bothers me is the fact that the user will have to restart his/her machine after the .NET Framework installation. This overhead is intolerable. I just want it to be opaque for the customer that he/she uses a smart client.
From my experince the .NET Framework installation never asked for restart (1.1 and 2.0), but a friend told me that he was asked to do it.
Does anyone know what are the cases which the .NET Framework asks for restart?
|
|
|
|
|
The .NET Framework does not require a restart - the service pack does (trust me - I help create them). If you go to MSDN and download just the RTMs a reboot will not be necessary (unless, of course, you installed a service pack and haven't reboot yet). When you install the service pack a reboot is required because files are in use. I can't go into details.
The best way is to write your own bootstrapper that eats the reboot code (return code 3010) and proceeds to install your application. You might warn the user that they should reboot later but it most likely won't be necessary depending on what native libraries or assemblies you use in your application.
Writing your own bootstrapper isn't hard. See Using the Setup.exe Bootstrapper Sample with an Application (.NET Framework Developer's Guide)[^] for more information and an example.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Ami Bar wrote:
Does anyone know what are the cases which the .NET Framework asks for restart?
Most modern installers need to restart a machine when some file they need to replace/upgrade is in use.
Yes, even I am blogging now!
|
|
|
|
|
Hello,
I have a ListBox with +/- 10 items (URL)
How to download from Internet these files (maybe with one or more threads).
P.S. Number of items may varies.
Many thanks for your help.
Frederic.
|
|
|
|
|
|
Yes, I know but how to transfer to webclient the contain of listbox (items) and how create many threads without dommage application ?
Thanks in advance.
|
|
|
|
|
...and Nick gave you the answer if you dig a little deeper into the application. The HttpWebRequest and HttpWebResponse define Begin* methods that asynchronously invoke downloads. This uses a thread pool to minimize CPU load by your process.
There is a catch: the default ServicePointManager that the requests use limit request to a host to 2. You'll need to either change ServicePointManager.DefaultConnectionLimit to another number before every instantiating a WebRequest object to another host, or create your own ServicePoint and change it's ConnectionLimit property accordingly to the hosts in your list.
In the future, if you have a question be more specific. If you ask a generic question it's hard to give you a non-generic, and if you don't provide details we can't know what you do and don't know, or what you've tried and haven't tried.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Hi
Is there anything like "Time to Live" for a Windows Form.
I want to close one after a few seconds. Is that possible?
I got VS 2003..
Greetings from Germany
|
|
|
|
|
Maybe I'm not understanding your question, but you can run a timer when your form starts up, then close the form after a certain amount of time lapses.
Any remotely useful information on my blog will be removed immediately. There are 10 kinds of people in the world. Those who have heard of the ubiquitous, overused, worn-out-like-an-old-shoe binary "joke" and those who haven't.
Judah Himango
|
|
|
|
|
The .NET Framework base class libraries (BCL) are a toolkit. Specific functionality like this is something you have to add.
In this case, all you need to do (if you're of the drag-n-drop variety) is to drag the Timer component from your toolbox in VS.NET onto your form. Set the internal you want (if by "a few seconds" you mean 3 seconds, you set it to 3000 (milliseconds). Switch to the event tab in the PropertyGrid and double-click the Tick event to add a handler. In the handler, add the following:
private void timer1_Tick(object sender, EventArgs e)
{
if (InvokeRequired)
{
MethodInvoker d = new MethodInvoker(Close);
Invoke(d, null);
}
else Close();
}This extra code is necessary because the event handler may fire on a different thread. You should not modify controls on threads other than the thread on which they were created, which is why the Control.InvokeRequired property and Control.Invoke method exist. The MethodInvoker is a standard delegate that takes no parameters and returns void. Often times you would have to declare your own delegates (which are like managed function pointers, or callbacks).
Don't forget to set the Enabled property to true. This would get set in InitializeComponent which is called from the constructor. If your form takes a while to open, you may consider overriding OnLoad (better than handling the Load event when you derive from a control that defines the event you want) and setting Enabled to true in your handler to make sure the timer doesn't start until your form is loaded (just before it displays).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
