如何在 Windows Mobile 中支持不同的屏幕尺寸？
我正在为 Windows Mobile 6.5 编写一个紧凑框架应用程序。该应用程序将在 Windowsphone Marketplace 中出售。为此，我必须支持各种屏幕尺寸和分辨率......但我该如何做到这一点？有最佳实践吗？我主要使用标准控件，但在主窗体中使用背景图像...我是否必须以任何分辨率存储它并动态显示它，具体取决于我的应用程序运行的设备？
感谢您的建议和帮助
托马斯
I´m writing a Compact Framework Application for Windows Mobile 6.5. The Application will be sold in the Windowsphone Marketplace. To do so, I have to support the various Screen sizes and resolutions...but how do I do this? Is there a best practice or so? I use mainly standard controls but a Background Image in the Mainform...do I have to store it in any resolution and show it dynamically, depending on which device my app runs?
Thank you for your suggestions and help
Thomas
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我首先要说的是，这是一个有争议的话题。
我个人的看法是，您应该识别明显不同的分辨率/尺寸范围，并提供一个不同的 UI 层，当您检测到从一个范围到另一个范围的调整大小时，您可以交换该层（动态切换甚至可能不是您的要求 - 在这种情况下）如果您只是在加载时检查）。如果您确定的范围非常有限并且彼此相似，那么这种方法显然没有意义，因为在同一范围内您的应用程序应该能够适当地调整大小。
尝试使用相同的 UI 层解决所有可能的解决方案可能听起来是个好主意，但它可能会导致灾难。你可能会让它工作，但你很可能最终会得到一个字符串球，其中有一堆 IF-ELSE 和 SWITCH 语句，用于查看像素大小、调整控件大小和移动物体。
如果您考虑一下，Google 地图（仅此而已，但请考虑任何 iPhone 应用程序）不会在移动设备和桌面浏览器等上提供相同的 UI。如果这就是我们讨论的大小差异（移动设备与类似桌面的分辨率），那么您将必须按照我上面的建议滚动不同的 UI 层。
圣杯是所谓的液体布局 - WPF 可以在这方面提供帮助，但由于您使用的是紧凑的框架，因此被排除在外。
我最近问了一个非常类似的问题 - 你可以看看它 如果您想阅读不同的意见。
I'll start saying this is a controversial topic.
My personal take is you should identify significantly different resolution/sizes ranges and provide a different UI layer you can swap in when you detect a resize that goes from one range to the other (dynamically switching might not even be a requirement for you - in that case you just check at load time). This approach obviously doesn't make sense if the ranges you identify are very limited and similar to each other, as within the same range your app should be able to resize decently.
Trying to tackle all the possible resolutions with the same UI layer might sound like a great idea but it can be a recipe for disaster. You might get it working, but you'll very likely end-up with a ball of string, with a bunch of IF-ELSE and SWITCH statements looking at pixel sizes, resizing controls and moving things around.
If you think about it, Google Maps (for one, but think about any iPhone app) doesn't serve the same UI on mobile and on your desktop browser and so forth. If that's the difference in size we're talking about (mobile VS desktop-like resolutions) then you'll have to roll different UI layers as per my suggestion above.
The holy grail is the so called Liquid Layout - WPF could help on this but since you're on compact framework that's ruled out.
I recently asked a very similar question - you can have a look at it here if you wanna read different opinions.
这是一个硬汉。我通过以下省力计划获得了合理的结果。 （顺便说一句，这是面向 Winform 的）
最大的问题是分辨率比预期小。因此，将屏幕创建得尽可能小，并特别注意锚点和停靠设置。显示每个表单时，将其设置为全屏，并且锚定属性应该以合理的方式合理地显示内容。
如果分辨率比预期大得多，这只会显得很愚蠢。
请注意，您可以通过 Screen.PrimaryScreen.Bounds 调用找到当前平台的屏幕尺寸。
This is a toughie. I've had reasonable results with the following low effort plan. (This is Winform oriented, btw)
The biggest issue is with resolutions that are smaller than expected. Therefore create your screens as small as possible and pay particular attention to your anchor and docking settings. When displaying each form set it to full screen and the anchoring properties should do a reasonable job of displaying things in a sane way.
This only starts to look silly if the resolution is MUCH larger than anticipated.
Note you can find the screen size of the current platform via the Screen.PrimaryScreen.Bounds call.
我最近构建了一个小应用程序，只是为了尝试一下。我需要显示背景图像，所以我无法使用Label等内置控件，因为它们不支持透明背景。
我最终使用 GDI+ 在窗体的 Paint 事件中绘制了整个界面。
处理不同的屏幕分辨率结果非常简单：界面原型是针对常规 96dpi 屏幕（最小），然后使用计算为 96/actual_dpi 的系数缩放所有尺寸。您可以使用找到的代码检索屏幕的实际 DPI 设置 这里（有点旧但仍然有效）。然后，我使用模拟器提供的所有分辨率测试了该应用程序，没有发现任何问题。
警告：我“浪费”了屏幕的下部，因此不需要任何特殊的东西来解决方形屏幕和横向/纵向方向。
I recently built a small app, just for trying things out. I needed to display a background image, so I could not use the built-in controls like Label and so forth because they do not support transparent background.
I ended up drawing the entire interface in the Paint event of the form, using GDI+.
Handling different screen resolutions turned out to be quite simple: the interface is prototyped for a regular 96dpi screen (the smallest) then all sizes are scaled using a factor calculated as 96/actual_dpi. You can retrieve the actual DPI setting of the screen using the code found here (a bit old but still working). I then tested the application with all the resolutions provided by the emulators and found no issues.
Caveat: I "wasted" the lower part of the screen so that nothing special was needed to address square screens and landscape/portrait orientations.