I developed an ElectronJS app that, on startup, opens a BrowserWindow on each available monitor. It works correctly as long as all monitors are configured on same display (display 0).
If I configure some monitors as display 0 and some others as display 1, the latter are not seen by the app and BrowserWindows are created only for the former.
I searched the documentation but I haven't found anything about how multiple display configuration is managed (or if it is not supported).
Is there any option (or workaround) to allow the app to see display 1 monitors?
TL;DR: X11 is not designed to work this way.
As this answer over at Unix & Linux SE indicates, only a single display per X server is supported. Thus, you'd have to spawn multiple X servers to get multiple displays -- and explicitly specifying devices to use is known to be problematic as my X11 configuration files have disclaimers like "Having multiple Device sections is known to be problematic" linking to this bug at X11's bugtracker.
Furthermore, the environment variable DISPLAY determines which X display is to be used by applications. Try echo $DISPLAY in a shell of your choice; it will most likely output :0, which is display 0. At not point at runtime can an X11 application decide that it wants to communicate with another X server, because it cannot determine if another one is present (or to what display address it would be listening). It only knows (from DISPLAY) which one it should be talking to.
Another point to make is that you cannot have the same desktop session running across multiple X servers without going to great lengths (see the above linked answer). Also, I do not think that even this would be possible with all desktop environments, as KDE Plasma for example binds to one specific X server (to be able to handle its own set of monitor configurations).
Related
I'm a newbie to both Web tech and Electron! I'm trying to build a desktop app with many windows and fields - including lookup/searches and retrieving data from a DB.
I believe I have most of what I need to get the job done except how to handle the communication between windows. I.e. I need a dialog that displays a table of customers where the user selects a customer to return the data to the calling window. So I pass the search string to the lookup dialog which displays the customer list and in the dialog the user picks the customer and returns the primary key to the calling window (which will display the customer information).
I have found several ways to do this on the web. But I can't imagine that I need to keep a list of all the windows (about 90) and include a listener for each in the main.js (main process) to allow communication between the windows. There must be a better way!! Is there a simple way to setup a universal routine to process communication????
If you're opening 90 windows you're going about this the wrong way. With Electron, every window runs in its own process. This means your app is going to have nearly 100 processes running which is going to be very slow on most machines.
Electron is a platform that brings web apps to the desktop. In a web app, if you want to show 90 windows you'd show them as HTML layers in a single browser window.
I have discovered several ways to open windows and add my html, css, and javascript to each of the windows. I also have discovered a way to create a global var in the main process and have the other windows to retrieve the information from the global var. So I guess I have avoided my concern of having to keep a list of the windows. Still I'm struggling with Electron - almost nothing is straight forward. Or maybe I should say - very little matches my experience with desktop programming languages.
Johnf
I'm using the following code in an application that automatically detects when it is run whether it is running as a service or desktop application and behaves appropriately for the situation.
JclAppInst.JclAppInstances('<application descriptive label>').CheckSingleInstance;
The code is embedded into an initialization block at the bottom of a unit that contains code responsibility for acknowledging the service status and displaying key desktop information so I know this unit is included in both modes of operation. The CheckSingleInstance call works perfectly in desktop mode making sure that only one instance is run but doesn't seem to be able to detect if the application is currently running as a service.
Unfortunately I can't work out why the JclAppInstances would be affected by the difference. Both instances are running from the same folder but are operating as different users (ie service user differs from desktop user) but my understanding is different users should work.
Does anyone know whether it is possible to do this with the JclAppInstances and if so what my problem is?
It seems quite clear that the JclAppInstances class doesn't support the required functionality and any solution based on using this Jedi component should refer to the following StackOverflow answer instead.
one instance of app per Computer, how?
Further to my previous question, I find that I cannot use the GExpertsDebugWindow on a PC which did not previously have Delphi installed.
If I have the following (not unusal, so probably of interest to others) requirements, do I need to roll my own code or is there and existing and free solution?
Must be able to read acorss the network (i.e., PC 1 monitors PC 2's debug output) by specifying PC 2's IP address
If posible, I would like to be able to filter by process name
Thanks in advance for any help
Microsoft's DebugView tool has those features. It can display OutputDebugString output, even from remote systems. Depending on other factors, it can even install itself remotely.
I'm writing an SSH/Telnet client for the Blackberry (and for other hand-held devices).
My question is more related to usability. Due to the screen size limitations for certain devices, and resolutions, how should I set the default rows/columns for the screen?
Currently I am setting it to 80 columns. The number of rows is dependent on the size of the font to prevent scrolling.
I have heard that 80x24 is the defacto default for most terminal types. Is this true?
For those SSH/Telnet users out there, how would you like your rows/columns set by default for a terminal client on a handheld device?
80×25 is actually more typical.
BTW. Don't know about BlackBerry, but for other smartphones and handhelds, there are PuTTY ports.
I prefer apps that detect the terminal size (with stty -a or the moral equivalent) and most apps do this. So I think the more important question would be, does your client properly report the size to the remote applications, so they can size themselves accordingly?
P.S. I'd be personally interested in such an app--the existing Blackberry ssh clients aren't great. If you want to follow up, my user name followed by my domain name ("reality") followed by the tld (com) may be used for sending electronic correspondence. (Screen scrape that, spambots!)
Most Telnet emulators uses 24x80 mode, which is used for VT100 type terminals.
Some users prefer a XTERM type emulator, which does not have a fixed width/height.
You can see my Telnet - ssh-2 version for blackberry at http://mochasoft.dk/telnetbb.htm
I understand that Window's Services have no desktop, and can't access any of the user's desktops directly (indeed, they can run when there is no desktop loaded). Why is it though that launching a form in a Window's Service causes an error?
A service should run without any user interaction, so there is no need for a form. If a service has to wait around for user feedback then it probably isn't going to be doing what it is supposed to.
You have to understand three related concepts: sessions, windows stations and desktops. But because there's a one-to-one relationships between sessions and stations, we can broadly ignore stations for this discussion. A session contains a station (winSta0 being the only interactive station) and stations contain one or more desktops.
Now session architecture differs according to Windows version. For NT <= 5 (XP/2003 and everything before them) services execute in session 0 along with the interactive user's apps. This is why you can configure services to interact with the desktop in these Windows NT versions - they are in the same session. For NT >= 6 (Vista, Server 2008 going forwards), services exists in session 0 but the interactive desktop is in another session. This is what's known as "service hardening", and is basically a security fix.
So since session 0 apps cannot get at the interactive console, it makes no sense for them to attempt to display a user interface of any kind.
Just to make this more confusing, Vista has a temporary kludge to cater for this situation: if an app in session 0 tries to create a dialog, Windows will trap this and present a warning to the user so they switch to a (I presume temporary) desktop where they can interact with the dialog. However this measure is explicitly temporary and you cannot rely upon it being in future Windows releases. I've seen this working in native code, but I suspect you are in managed code and the runtime is being smart enough to catch your behaviour and deliver a metaphorical slap to the hindquarters :-).
Ummm... what and whose desktop is that form going to appear on, exactly? A 'desktop' is an operating system concept: each window handle is owned by a specific desktop within a window station belonging to a single (interactive) user. The process within which the service is executing isn't going to find the user's visible desktop in its window station. For a rather dry reference, look at MSDN.
Actually, it's even nastier. You might be able to configure permissions for the service to be able to create a desktop -- but then nobody will see it! Alternatively, you could grant the process the rights to switch desktops, and confuse the heck out of the user!
There's a setting you must enable in order to allow your Windows Service to access certain folders directly (like desktop) or show forms (including MessageBox pop-ups): "Allow service to interact with desktop"
To see this, right click on My Computer => Manage => Services and Applications => Services. Double-click on a service to access its properties. On the "Log On" tab there is a checkbox for this setting.
Here is an article for how to set it programmatically in C#
[Edit] As Stephen Martin points out in the comments: this is only valid advice for pre-Vista versions of Windows.
Because if nobody is going to see the Form, nobody is going to dismiss it - running a modal dialog is a recipe for a hang - so you want it to complain loudly when this happens rather than sit there quietly until you kill the process (or look at a stack trace to determine what'd going on). (The other obvious problem is, who is going to pick the DialogResult if there is more than one possibility?) You want to know when this is happening. (Assert dialogs that dont throw if they cant show anything are a fun way of making people mad.).
In other words, because you want to know when things are confused enough in your code that a dialog is being shown within a service context.
(I'm assuming you're using Windows Forms on .NET, eve though you didnt tag it as such)
(If you have correctly configured things such that the service is allowed to interact with the desktop, you won't get an Exception)
When a Windows Service is started it is assigned to a Window Station and Desktop according to well documented, though somewhat obscure rules. As mentioned elsewhere it is not assigned to the interactive desktop (unless it is set to interact with the desktop on a pre-Vista OS) but it definitely runs in a desktop.
It is a common misconception that services cannot use UI elements. In fact many services (such as SQL Server) have in the past used hidden windows and windows messages for thread synchronization and work distribution purposes. There is no reason that a Form cannot be shown in a service. If you are getting an error it is due to something you are doing with the form or some component that is on the form. The most likely issues have to do with whether or not you need an STA thread for your form or are you creating a message pump for your form or something similar.
While you certainly can use a form in a Windows Service you almost certainly shouldn't. There will be threading issues, cross apartment call issues, possible blocking UI issues, etc. There are a very few situations where using a window in a service is a good choice but there is a better way, with no UI, in 99.99% of all cases.
Because at the time when the operating system needs to paint the window there is nothing to draw the form on.