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 :)
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.
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.
After mild frustration with the difficulty to make top-level "plain old folders" within Eclipse for visual-organization purposes, I discovered that the thing I'm after is called a "working set". Hooray! But they don't seem to be rename-able, by any of the apparent avenues (right-clicking on it or using the Configure Working Sets window).
Is that just the way things are, since no one should be so lazy as to refuse making a new working set with the right name and transferring everything over? Or am I missing something obvious?
I also have a more minor question whose answer I already think I know. Can I tell a specific working set not to change its icon to have the "red X" when one of its children has an error? Nothing in the preferences under Debugging suggests to me the ability to turn off the automatic icon-changing. It's a useful feature, but I have a few simple practice projects with very basic errors, and I don't need the visual reminder to "fix" them, especially if they're in my "Practice" working set, whose icon I'd prefer not to change.
To rename a Working Set, you need to get to the dialogue of selecting a Working Set (click on the white down arrow at the top right of the package explorer > Configure Working Sets..), focus on your Working Set and click the "Edit" button. There, you can change the Working Set's name, as well as what's actually included in the Working Set.
There is no way (that I know of) to change the icon display to avoid showing the errors marker.
I have been experiencing a strange issue in Flex Builder 3 where certain dialogs such as the Add New Project wizard and the SVN Commit dialog are completely empty save for the title area.
I'm running Flex Builder v3.0 (build 3.02.2.214193) on the Windows 7 RC. I have tried completely uninstalling and reinstalling Flex Builder to no avail. I don't think it's Windows 7 causing the issues because it was working a couple of months ago with no problems. Even more strange is that I have not installed any additional plugins or made any configuration changes to Flex Builder between the time before these problems began and now.
Has anyone else encountered this problem, and if so, know of any solutions?
Here are a couple of screenshots to illustrate the behaviour.
alt text http://www.colincochrane.com/image.axd?picture=2009%2f9%2fdialog2.PNG
alt text http://www.colincochrane.com/image.axd?picture=2009%2f9%2femptydialog.png
You are probably running Logitech SetPoint. Try killing all setpoint processes. (you don't even have to restart flex). It worked for me :-S
According to this Adobe forums post, there are multiple causes:
SetPoint (as indicated by Scheea)
Wacom Tablet drivers
In addition, comments suggest the following:
UltraMon
These seem to suggest that the cause is any program which monitors keystrokes or mouse movement.
Workaround: In the new wizard dialog above, note the question mark on the bottom left (the help button). When you click on the help button a help panel is added to the dialog on the right separated from the main dialog by a splitter. When you drag the splitter the rest of the dialog appears. You may need to scroll to a position where you can see all of its contents, but it should become usable. Resizing the dialog alone was not sufficient for me.
In addition, I couldn't fully use the mouse to select elements so I had to type into the filter field in order for the correct projects to show up.
I had the issue with Window7 x64 Ultimate with FB3 Pro and shutting down Set Point seems to have fixed the issue.
For me it was Set Point and Display Fusion (allows you to set up multiple background images as wallpaper on multiple monitors). Took a lot of hair pulling to figure this out.
I need to draw a few small undecorated windows on top of another app's window. Each of these windows contains just a short label. It works fine but the windows are too big for my purpose. It seems as if Windows doesn't allow smaller than 104 x 27 toplevel windows, I might be wrong. I haven't tested on another backends. I'd like to shrink them to just the size needed to display the label. Is there a way to accomplish this?
Trying out things, I figured that setting the type hint with gtk_window_set_type_hint to GDK_WINDOW_TYPE_HINT_UTILITY allows the window to shrink horizontally but not vertically. I'm not sure what other implications this has. But it didn't solve the problem anyway.
I'm looking for a portable solution but platform-dependand answers are welcome too. Any help appreciated.
Edit: As usual, the solution is trivial. I had completely forgotten the GTK_WINDOW_POPUP window type.
Edit: Making the window GTK_WINDOW_POPUP has some unfortunate side effects which make it unusable for my purpose. I eventually got GTK_WINDOW_TOPLEVEL to work as expected. The key was to do gtk_window_set_resizable(window, FALSE) after the the window has been exposed.
Use gtk_window_set_resizable, this affects user resizes, which apparently includes resizes requested by the window manager. Setting it to FALSE therefore makes the programmatic value stick.