i have just designed a business information dashboard for the customer. The initial design was for a 1280x1024 screen res but it now appears that the customer has a 1024 x 768 res. This BI form is a child window of a MDI interface and as such there is a header and statusbar which means if the application is fullsized then it is occupying 1024/768 - the windows taskbar and my form has this available size minus the size of the header and statusbar of the MDI application. I can deal with this but i want to make the application customised specifically for the size of screen most frequently used which it happens is his.
Does anyone know of any places within the registry or any tools etc which can tell me the size of the window/form as it is being viewed?
Cheers
tim
I've not done any MDI stuff, but from a quick playaround I believe this might help. I put the below into a child form.
label1.Text = this.Parent.ClientRectangle.Width.ToString() + "x" + this.Parent.ClientRectangle.Height.ToString();
It seemed to return the inner size of the MDI parent. As I added more toolstrips and a status strip the height reduced.
Hope this helps.
EDIT:
Strange, this doesn't seem to bring back the parent form name (hmm a puzzle).:
label1.Text = this.Parent.Name;
EDIT 2:
but this does (note the 2nd Parent - now I'm confused):
label1.Text = this.Parent.Parent.Name;
EDIT 3:
Ok, after a couple more tests...
1. this.Parent.ClientRectangle //this seems to be the size in the MDI form - NOT including toolbars/statusstrips/menustrips etc.
2. this.Parent.Parent.ClientRectangle //Having TWO parents seems to be the main MDI size - no matter how many strips added in this seems to return the size - not including the window titlebar.
Apologies for the edits.
Related
I have a WinForms project based heavily on the DevExpress Windows Forms suite. I am working on a control that appears as below:
I use the term programme to differentiate between training programmes for people, from program, meaning computer program. In the image there are 3 ProgrammeGroup user controls. Each has a header, with 2 combos, and below that, a ProgrammeDetail user control with programme details.
When the top, left combo shows a value of Yes or blank, the programme details must be visible, otherwise not. When making a ProgrammeDetail control invisible, I also set its Height to zero, and the outer ProgrammeGroup control shrinks on auto-size.
However, if I set the Yes/No combo on the middle ProgrammeGroup to No, that
ProgrammeGroup shrinks, but leaves a gap between the header only middle control and the bottom control. This gap is visible in the following image:
How can I lay my ProgrammeGroup controls out so that if one shrinks in height, all those below it are moved up, meaning no empty gap. I am hoping that one of the many different panels in the DevExpress WinForms suite can help me do this, but I am stumped at finding one.
Solution to this problem is using FlowLayoutPanel which automatically align controls inside it next to each other.
The best way to adjust sizes and locations of child controls is to place them onto LayoutControl. This control is specially designed for such tasks. To hide unnecessary layout items/groups, use the BaseLayoutItem.Visibility property.
I should also note that LayoutControl is flexible and supports different modes including the Flow Layout Mode.
See Also:
Customization Form
I am new in WPF if there is something wrong please co-operate.Here i require some idea from experts.
I am working on one application in which i have to show some content on WPF form after filling the fields present on the form.On the same form i also have a print option.
Check this image.This is my form here part in the red block is generated at runtime.When i click on the print button it only show the visible part on the paper and skip the remaining part.
Problem :
How i can move the remaining part of the form which is under scroll to next page when i click on print.
For example in the given image we can see only 2 bulls eye completely and next 2 partially.How i can shift this remaining part to next page only when i click on print.
The answer is quite easy : don't rely on your window to do the printing, but build the visual you want then print it.
For instance, you must have a function that creates dynamically the circles and so on, then adds them to a Panel. What you might do is to print the Panel.
Or if you prefer, you might build Dynamically a new window, where you put all the Data you want printed as you want, then print the window. The advantage of this method is that it is more flexible for the content (if you want a header/footer) and also you can watch the content easily for debug. Note that even if the Window content is dynamic, you can have a base window for printing that avoids you to do too much xaml with code (expl : you might have TextBox bound to a PrintTitle property that you setup in the constructor of the Print Window...).
Notice that visual that were not rendered on screen will not print. Be sure, to avoid the common issues, to have a look at this article from this great site, switch on the code, here :
http://www.switchonthecode.com/tutorials/printing-in-wpf
Edit (reply to the question in comment):
1) If you have fixed number of bulls eyes, just make one Window for that number and Print it, this is waaaay easier.
2) To put Visuals in pages instead of rows, you'll have to rely on page Width/Height. What matters is the size of your control vs size of page. In the example, they build (in OnRender) Controls having LineHeight, LineWidth as size. Do the same : Try to put as many line of control as you can such as
(Control Height + margin )*NumberOfControlPerPage < Page Height.
Then you have to change OnRender to render controls instead of Rows made with rectangle+text. Pack your controls two by two in Horizontal StackPanels Then pack those StackPanel into a vertical StackPanel, then render. You have to keep track for each page which control was rendered last, then resume rendering at the following control.
Please follow this link.This is the basic which i got after searching in web world.Using this basic detail you can do any thing with print in WPF
I am trying to remove the border of my WPF window in the design view/tab in Visual Studio. Please don't mistake this as a request to create a border less WPF window. I did that and it is working fine. What bothers me is that even if you have set WindowStyle = None, ResizeMode = NoResize, the design view/tab still shows a border around your window in the preview.
Is there a way to remove said border and have a 1:1 preview of the border less window as in Windows Forms?
Every question I have found in regards to this only asks how to remove the border of the actual application. I would like to remove it in the preview.
Any help would be very much appreciated :)
here is a screenshot of my problem:
This cannot be done as this is just how Visual Studio renders a window in design view (I think the frame is probably there so that you can distinguish when you are editing a Window rather than a UserControl).
Rather than try and find a solution to this I would ask myself if this is something I need to be spending time figuring out - after all you say that your program works correctly when being run. I think your time will be better spent writing code for your program rather than trying to play with the design time environment.
Update: In response to you comment, consider that the window frame will be different on every users machine depending on their operating system version (XP vs. Win7) or the theme the user has installed.
My computer has XP installed so the side borders are a lot thinner than those shown in design time so any content will be smaller (but only my a few pixels - 4 in my case; does your user interface design really depend on 4 pixels?).
When using a technology such as WPF you should not be designing your UI to fit to exact pixel sizes; you should be designing with min / max values or using layout containers that adjust to the size of the window as set by the user. Any regions in your UI (E.G. sidebar and main content) should be expressed as a ratio or percentage of one another; instead of saying "The side bar is 150 pixels wide and the main content area is 350 pixels wide" you should be saying "The side bar takes up a third of the window width and the main content takes two thirds".
Although the question is very old and have already been answered (kind of), I just realized: if you set WindowStyle="None", your undesired border is gone.
We have a WinForms application that includes controls such as picture boxes that are positioned on a form. The base application is in English.
We've translated this application to a number of different languages (French, Spanish, Danish, Greek, etc.) and most recently to Simplified Chinese. The translated application works perfectly on our operation systems (English).
One of our customers installed the application on their operation system, Windows XP in Simplified Chinese. The layout of our application is broken. Simply put, the elements are pushed to the bottom right by a factor that is proportional to the distance between the element and the top left corner. For example, an element at the top right corner in design view is pushed off screen to the right whereas the items at the bottom of the page are pushed downwards and to the right.
The application supports switching languages while in use. When the locale is en-US, there are no layout issues. When switching to Simplified Chinese, the issue appears, but only on the Simplified Chinese operating system. The screen resolution and DPI are the same.
Do you have any ideas? I'm sure it must be a simple configuration setting somewhere, but I have been unable to solve this issue.
The size of the system base font matters as well. Which is indeed something you can change on XP. This will invoke the form's auto-scaling logic, designed to ensure that the controls grow larger to fit the larger font size.
This is by design, controlled by the form's AutoScaleMode property. Don't change it, rescaling is important. Just make sure the form layout still looks good, use properties like Anchor and Dock, controls like TableLayoutPanel, FlowLayoutPanel. Or the Resize event for tricky ones.
Paste this into your form to test this logic without having to change system settings:
protected override void OnLoad(EventArgs e) {
this.Font = new Font(this.Font.FontFamily, this.Font.SizeInPoints * 125 / 96);
}
I'm designing some dialog boxes, and I'm having a hard time to fit everything. (and it has to fit on a single dialog box by design, so please don't tell me I should make two dialogs instead of one:))
I'm wondering what's the max size a dialog can have before being annoying for the end user. Of course it should't be bigger than his resolution, but are there any other boundaries to consider?
I'm trying to limit at 800x580 (so that it can display fine on a 800x600 screen without hiding the taskbar), but I expect my users to be on 1024x768 or better screen resolutions.
Is a 800x580 dialog box ok, or is it too big?
Have you considered using a tabbed layout?
Also, I believe the smallest main-stream screen resolution is 1024x600.
I'd say anything over that is too big. I try to stick below 1000x500.
I'm writing this on a netbook (ASUS) with resolution 1024 x 600. I've also noticed this is a defacto standard for most other netbooks too.
Another option: you could create a dialog that resizes itself automatically to fill the current desktop (except for the task bar).
It could also enforce a "flow" style layout for it's child controls. This would ensure the best use of the available space is made.
To get "flowing" in Windows forms you can use either the flow layout control or (for a richer interface) the WebBrowser control.
By the way, modal dialogs seem to be less popular as a way of user interaction these days. Especially large dialogs containing a lot of information/controls. This article has some good alternatives.
I think that if the user NEEDS to see all data on screen at the same time... and you can fit everything in 800x580... I think that it's a fine size.
If you know all users have bigger resolutions so don't struggle... that size is OK.
However... a way of showing lots of information and being able to edit it... could be a PropertyGrid control (an example here)... may be that could shrink a bit the form if you don't feel confortable with it being so big. Don't know if it a possibility given the needs of your client/user.
Just hope that no-one ever tries using your app on a media center running through a standard definition display. That's 640x480 for NTSC. I've suffered this problem with quite a few apps.
Whatever your pixel by pixel size, if it takes more than a few seconds for skilled users to complete the use of your window, then it shouldn’t be a dialog. Anything longer is annoying. You’d be asking your users to do too much work that is too easy to lose (e.g., by hitting Cancel accidentally) and too hard to re-entered (e.g., between sessions). If you have so many controls that the dialog needs to be 800 by anything, then it’s too many controls. 200,000 square pixels and 40 controls is the very most you should consider for a dialog. And tabs are nature’s way of saying your dialog is too complex.
Dialogs are for entering parameters to execute a single command on one or more data objects visible in the primary window for the dialog, which is why dialogs need to be small and simple. I suspect that’s not what you’re doing. Instead, you’re using a “dialog” to represent the main data objects and carry out a major task, not a single command.
What you want is a primary window, not a dialog, with all the support necessary for the complicated task you’ve set up for the user. That includes providing a means for users to save, retrieve, and copy their work. That means a menu bar and toolbar with all the standard commands, including help. The window should absolutely be modeless, and be resizable, maximizable, and minimizable.
Primary windows should be designed to work best at the size of most (over half) of your users’ screens. 1024x768 is generally fine for today’s laptop/desktop screens, not that you should use that much space if you don’t have to. If the user’s screen is smaller, or the user for any reason resizes your window below the design size, then scrollbars should appear to allow full access to all controls and content in the form –just like any primary window. The experience on the web indicates that scrolling is not a showstopper for forms.
Beyond that, tabs may be used in a primary window to increase the number of controls on it. You said you don’t want to hear about multiple windows, but multiple windows should be used instead of tabs if the user will be comparing data across tabs/windows. You can also fit more in a given primary window size by using a compact presentation (I describe this at http://www.zuschlogin.com/?p=42), but test such an approach on your users before committing to it.