我正在设计一些对话框，但我很难适应所有内容。 （它必须根据设计适合单个对话框，所以请不要告诉我我应该创建两个对话框而不是一个:)）
我想知道在最终令人烦恼之前对话框可以有的最大尺寸是多少用户。 当然不能大于他的分辨率，但是还有其他的界限需要考虑吗？
我试图将分辨率限制在 800x580（以便它可以在 800x600 屏幕上正常显示而不隐藏任务栏），但我希望我的用户使用 1024x768 或更好的屏幕分辨率。
800x580 的对话框可以吗，还是太大了？
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?
发布评论
评论（5）
您是否考虑过使用选项卡式布局？
另外，我认为最小的主流屏幕分辨率是1024x600。
我会说任何事情都太大了。 我尝试将分辨率保持在 1000x500 以下。
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.
我在分辨率为 1024 x 600 的上网本（华硕）上写下这篇文章。我还注意到这也是大多数其他上网本的事实上的标准。
另一种选择：您可以创建一个自动调整大小以填充当前桌面（任务栏除外）的对话框。
它还可以为其子控件强制执行“流”样式布局。 这将确保充分利用可用空间。
要在 Windows 窗体中实现“流畅”，您可以使用流布局控件或（对于更丰富的界面）WebBrowser 控件。
顺便说一句，模式对话框作为一种用户交互方式现在似乎不太受欢迎。 特别是包含大量信息/控件的大对话框。 本文提供了一些不错的替代方案。
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.
我认为，如果用户需要同时在屏幕上查看所有数据...并且您可以将所有内容放入 800x580...我认为这是一个很好的尺寸。
如果您知道所有用户都有更大的分辨率，那么不要挣扎......这个尺寸就可以了。
但是...显示大量信息并能够对其进行编辑的方法...可能是 PropertyGrid 控件（这里是一个示例< /a>)...如果您对这么大的表格感到不舒服，可能会稍微缩小表格。 不知道考虑到您的客户/用户的需求是否有可能。
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.
只是希望没有人尝试在通过标准清晰度显示器运行的媒体中心上使用您的应用程序。 NTSC 格式为 640x480。 我在很多应用程序中都遇到过这个问题。
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.
无论您的像素大小如何，如果熟练的用户需要几秒钟以上才能完成窗口的使用，那么它不应该是一个对话框。 时间再长就烦人了。 你会要求你的用户做太多的工作，这些工作很容易丢失（例如，通过意外点击取消）并且很难重新输入（例如，在会话之间）。 如果您有太多控件，以至于对话框需要达到 800 个，那么控件就太多了。 对于对话框来说，200,000 个方形像素和 40 个控件是您最多应该考虑的。 选项卡本质上是在表明您的对话框过于复杂。
对话框用于输入参数以对对话框主窗口中可见的一个或多个数据对象执行单个命令，这就是对话框需要小而简单的原因。 我怀疑那不是你在做的事。 相反，您使用“对话框”来表示主要数据对象并执行主要任务，而不是单个命令。
您想要的是一个主窗口，而不是一个对话框，并为您为用户设置的复杂任务提供所需的所有支持。 这包括为用户提供一种保存、检索和复制其作品的方法。 这意味着菜单栏和工具栏包含所有标准命令，包括帮助。 窗口绝对应该是无模式的，并且可以调整大小、最大化和最小化。
主窗口的设计应在大多数（超过一半）用户屏幕的尺寸下发挥最佳效果。 1024x768 通常适合当今的笔记本电脑/台式机屏幕，但这并不是说如果不需要的话您应该使用那么多空间。 如果用户的屏幕较小，或者用户出于任何原因将窗口大小调整为低于设计大小，则滚动条应该显示为允许完全访问表单中的所有控件和内容 - 就像任何主窗口一样。 网络上的经验表明，滚动并不是表单的阻碍。
除此之外，可以在主窗口中使用选项卡来增加其上的控件数量。 您说您不想听到多个窗口，但如果用户要跨选项卡/窗口比较数据，则应使用多个窗口而不是选项卡。 您还可以通过使用紧凑的演示文稿来适应给定的主窗口大小（我在 http: //www.zuschlogin.com/?p=42），但在实施之前先对用户测试这种方法。
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.