I have a question about form appearance.
I would like to create an application that looks likes some MacOS app (for example Bear or even the App Store. These application are characterized by the left part (a sort of drawer) that is of on1y one colour.
I would like to have my forms created with Delphi in the same way.
I've looked at the internet and I've tried, as suggested, to use VCL style, but there are some problem due to Windows dpi setting on the various PC that run the application. So I wonder if there is a way to reach this task coding.
In the image below you can see how a normal window appear in a PC with Windows 10
The example is greeting with a simple form in which I put a panel painted of blue.
As you can see the titlebar of the windows is white and it can be painted with a color using the VCL styles (but in this case all the titlebar should be of that color.
What I would like to have is something like the following image (created in Photoshop )in which I've traced a red line only in order to highlight the titlebar:
I've tried with intercepting WM_NCPAIN or other similar solution but I can't find a way to reach my task.
Can someone help me with this problem?
Many thanks in advance
In Windows Vista and later, the appearance of the non-client areas of application windows (the title bar, icon, window border, and caption buttons) is controlled by the DWM (Desktop Window Manager). Using the DWM APIs, you can change the way the DWM renders a window's frame. (quote from MSDN).
There is an article Setting up a custom title bar on Vista/Windows 7 that explains how to do this using Delphi. The article also applies to Windows 8.x and Windows 10. The author has written a number of articles on the subject; you can find an overview here.
Related
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
Background
I have a Gtk application running on a custom Linux distribution (based on Yocto running Waland/Weston). The application is developed on Ubuntu 20 which has both X11 backend and Wayland backend. The child dialogs or windows that are spawned by the main window are perfectly centered on the main window (in Ubuntu on both backends). However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Different Approach?
With what ever little I know I tried Gtk::Window::move, Gdk::Window::move and even dared to play with Wayland surfaces (gdk_wayland_window_set_transient_for_exported ) but with no avail.
That left me wondering how the user is able to move such child windows by grabbing the header bar (or title bar as Gtk::Window calls it) even under Weston. If I get to know how this works then perhaps I can emulate a grab-drag to position the window where ever I want.
I tried sifting through gtkwindow.c to find out what happens when one sets the title bar using the function gtk_window_set_titlebar but the rabbit hole went a little too deep.
It would be great if someone can point me in the right direction, at least quote some functions whose implementation I can study to get this working....
Your question consists of multiple smaller ones, so I'll try to give a shot at answering each and one of them.
The general idea is that Wayland is quite minimal, so to make it suitable for desktop use cases, you need a protocol extension. This extension is called XDG Shell.
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
This first part is described in the Wayland book, but the idea is that you forward an input event (usually a drag) back to the compositor, who will know what do with it. That might mean moving the window (or not moving it, if you've reached the edge of the screen.
However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Note that your confusing 2 questions here: one is where to put a child window, compared to a parent window, while the second sentence here talks about position any toplevel window. There is also a section in the Wayland book on popups (part of XDG shell also) which also describe something similar.
So whether you can arbitrarily move windows: the answer is no.
The most important question then becomes: what can you do to solve your problems with Weston? It's hard to say without any kind of code. You might want to make sure you set the GtkDialog parent when constructing it (also known as the transient_for property. You might want to play around with the modal flag also. There might be other options too, but it's a bit of a blind guess.
Is it possible to make an extension that draw lines on the background? You can decorate a lot of thing but I can't find a way to draw colored lines.
I would like to see the flow of my data (inspired by visual programming).
Something like that (but the like drawn under the text) :
Keep in mind vscode is an add-on to Electron, which is a webbrowser in a desktop raiment. So what you see are webpages and hence everything what's possible on a webpage (with a node.js basement) is also possible in vscode - at least in theory. I say "in theory" because after all vscode is a text editor and limits interaction in a way that supports this goal. So, what you can is either some drawing/graphics or add extensions that work in normal editor pages. You certainly don't want to write your own text editor interface within vscode.
I have recently upgraded from Delphi7 to Delphi XE5 and one of the differences that first jumped out at me is that by default, the IDE sets a forms default position to be in the top left corner of the screen instead of the center of the desktop like it was in D7 and I have looked all around in the options menu and have yet to find a way to set it so that when a new project is created, all forms default to be positioned in the center of the desktop and was hoping I was overlooked the option to do this or to confirm if it was not possible to set this option to be default.
I know there is the little box at the bottom right hand side of the form designer pane which allows you to move the form around so it is placed anywhere on the screen and of course you can set it to be in the center of the screen using the object inspector, but if I could set it to default to this position by "setting and forgetting" an option in the IDE, than that would be one less thing I need to bother with when starting a new project.
Anyway, any help would be appreciated and thanks in advance for any and all replies.
I figured it out myself in a roundabout way. It does not answer the question to the exact specifications that it was asked in but it works out close enough for my needs. The trick was to set the (now hidden) "Embedded Menu Designer" option to FALSE in the registry which causes the form to float independent of the rest of the IDE like it used to in Delphi 7.
Why this option was hidden from the options panel in Delphi XE3 and above is beyond me, but at least there is a way to get it back to the classic look I was after.
Source: http://theroadtodelphi.wordpress.com/2012/09/04/disabling-the-embedded-designer-in-rad-studio-xe3/
Note: The article talks about XE3, but the same technique applies to other Delphi versions as well. All that needs to be changed is the version number in the registry branch needs to match the version of Delphi that is being using. Everything else remains the same.
Isn't poDesktopCenter (TForm.Position property) enough? You set it in design time and forget about this.
I don't know what will happen if you have 1500x1200 form and the screen resolition is 800x600 - try it youself :)
I have a black background of the code editor but a popup window with code completion has a white color with highlighted text.
How to change a background color or disable the highlighting?
It appears that the colors of the pop-up code completion and Javadoc windows are not directly configurable from within Netbeans.
It appears that the only way to accomplish this is to change the color scheme of your operating system's desktop to have black-backgrounded windows. (That means, of course, that all of your apps will have a black background.) This was tested and confirmed in Netbeans 7.3 development build 201212140001. Using Netbeans 7.2.1 there were some issues with this. Notably that the black background was present, but the text of the code completion and Javadoc windows were too dark. This was reported as part of and fixed in Bug 134281 for 7.3.
I would suggest that if you would like the code completion and Javadoc pop-up windows to match the editor color theme without having to change the OS color theme, that you see if someone has already submitted a similar request on Netbeans's "Issues = Bugs, Feature Requests, and Enhancements" page. If so, vote for it. If not, submit one yourself. Be sure to differentiate it from #134281 which dealt with accessibility and OS color themes.
I'm involved in a project that is attempting to use the Eclipse RCP splash screen to gather user credentials, language, etc. If this screen loses focus, it is not available (under Windows at least) through the ALt-Tab functionality, and can only be found by minimizing all other windows and uncovering it. Any way of having this screen allow itself to be activated in this way? They're avoiding creating an intermediate screen, for reasons unknown at this point.
I think it might be time to examine those unknown reasons. Even eclipse doesn't use the splash screen in this way. If it needs to prompt for information, it opens a new dialog to ask for it.
Good luck.
[Edit] I stand corrected. This thread seems to have a solution to this. Good luck, I'm no SWT/RCP guru.
See this page. From one of the comments:
The splash screen window is created natively with the extended window style WS_EX_TOOLWINDOW which makes it not appear in the task bar. This corresponds to the SWT constant SWT.TOOL.
I don't know if it's possible to change the window style after it is created on Windows. You can always drop down to JNI if that's necessary.
Create your own implementation of AbstractSplashHandler.
When creating the shell, don't use the SWT.TOOL style.
The shell will be accessible through the windows task bar.