Well
this is a really simple question, the search tearms are just not that great.
How do I check in some library if I am currently running as a console application, vs. a WPF window application?
Thanks for any tips,
Chris
You can check whether the current thread is a WPF UI thread by checking Dispatcher.Current.
There's more, what if your library method is called from a worker thread? You didn't tell why you need to know, preventing a good answer. One approach is that the app that uses your library never has any trouble knowing whether its console or WPF. Expose a property to allow it to tell you. Another is using events so the app can simply implement the event handler to its liking. Dependency Injection is another.
You can check if the executed statements are running in a WPF host with the following statement:
if (System.Windows.Application.Current != null)
{
//statements for WPF mode
}
else
{
//statements for non WPF mode...
}
For this you must reference PresentationFramework.dll
ILDasm will have an entry in the manifest as follows :
.subsystem 0x0003 // WINDOWS_CUI
.subsystem 0x0002 // WINDOWS_GUI
based on the subsystemtype you can tell if its GUI or CUI.
This information is also available from the following command :
dumpbin ConsoleApplication1.exe /headers
From your library query for entry assembly and get its full path(Assembly.GetEntryAssembly().CodeBase) and then you can issue any of these command to know the subsystem.
Related
I want to make a GUI Windows application that can run console applications. When this happens, the console window should not be shown. Instead its content should be shown in a visual component (memo/richedit). This component should show exactly the same content which would appear in the console window, even the color of the text and its background should be displayed. So this visual component should work exactly as a console window. I know that the standard output can be captured but many console applications do not use it. Is it possible to capture the output of a console application this way? Are there Windows API calls that can handle this?
I use Delphi XE2 but C# code would also be helpful.
You have to run the console mode program with stdout redirection to a pipe that your Delphi program will create. Your Delphi program can read the pipe to get the console mode program output and do whatever it needs to. By the way, this works not only with Delphi but also with any language able to create pipe and run program with I/O redirection.
If you need Delphi code to do that, have a look at this reference.
There is a ready-to-run component on GitHub: DosCommand
The Demo shows two ways how to do what you describe.
I am not sure if it works for older versions like XE2, but at least you can give it a try.
Traditionally you would call CreateProcess with stdin/stdout set to pipes you created. This should work for most programs but not for anything that uses a ncurses style "GUI" and you also lose the color information. An example can be found on MSDN.
Windows 10 (1809?) added support for pseudoconsoles. This is used by the new Terminal application and is your best bet for full console compatibility.
The last alternative is to inject into the child process and hook WriteFile, ReadFile and all the console functions but this is ugly and error-prone.
CefSharp allows to be started in single-process mode when passing the command line argument --single-process. Is there a way to enable this from the application itself (programmatically, on startup, by default)?
I don't see it anywhere in CefSharp's code. The flag might be captured somewhere lower-level.
Single Process mode is not supported in CefSharp (It's not supported in CEF either) so we don't expose a way to programmatically set the relevant property.
http://magpcss.org/ceforum/apidocs3/projects/%28default%29/_cef_settings_t.html#single_process
There are many scenarios where things just crash. See http://magpcss.org/ceforum/viewtopic.php?f=14&t=13259&p=28501#p28501 for one such example.
Basically use at your own risk.
I need to write a very small application which writes some system data to a file and then exits. I could do this in a console application but I have no need or desire for a console window to appear during this process.
I would normally use a Windows Forms application with no forms, execute the code in the Main method and then allow the application to exit, however, this time I couldn't help but wonder if this is the best way to do it and whether you could do it with a WPF application instead, what the differences are and whether or not once you've remove any forms/windows and unnecessary reference, it matters or not.
WPF and WinForms are two different libraries that show UIs.
If you never show a UI, you aren't using either of them.
You should start with a WinForms project (WPF projects set extra project metadata that you don't want), then delete the reference to System.Windows.Forms.dll.
Alternatively, start with a console project, then change the Output type to Windows Application.
Windows Forms with no window or console app with the type changes to windows application will give you the same result which is a simple app with Main() method and now windows.
WCF will only make sense if you actually want to display something as you're not going to use any of its features in your case.
I have a winforms applications which is reading strings using sockets and the sockets are under backgroundWorker thread.
Things are working fine, but as per the new company standards my manager wants it to be run as service rather putting this winforms application in the startup folder always.
The problem is that we are using below line of code in this winforms application
Invoke(new MethodInvoker(
delegate { _logger.Error((String.Format("Error: {0}", _socketError))); }
));
Can somebody guide what ca I do to use the above line of code in the windowserverice project
please suggest
Thanks
Update: I need to use invoke because this statement is running in the DoWork event of backgroundWorker component.
Since _logger is just writing to a log file, I do not understand the original intention behind using Invoke in the first place. I think you will be safe replacing that line with:
_logger.Error(String.Format("Error: {0}", _socketError));
I have put some code inside of the public MainWindow() {} but I kept getting some obscure XAML parsing errors as soon as I did that (not on my computer but on 3 others I've tried it on - yep!)
Is there the preferred way to run code AS SOON as t he application starts?
The theory is I want it to call home and ask it it's ok to start. If it's not, I want the app to close out. Call it a makeshift copy-protection :)
Under normal circumstances, WPF creates the Main method (the entrypoint of the application) for you. Your options
Create a handler for the Application.Startup event and put your code there. Alternatively, you can override the OnStartup() method.
If that's too late for you, put your code in the App's parameterless constructor (it probably doesn't exist, but you can create it).
If even that's too late, you can create your own Main() method. There are several ways how to do that. Probably the easiest is to put it in another class and tell Visual Studio you want to use this method in the project's properties.
On the other hand, you said you're getting some obscure XAML parsing errors. Maybe you should figure out what exactly do they mean?
You have Window.Loaded event in WPF.
But if if you want to check for run permission before application loads ( due some resource consuption or some business strategy) use a bootstrapper a separate small executable that first launched by mainexe and after if everything ok a bootstrapper runs main exe