Compact Framework 最佳实践：构建 GUI
我正在维护一个使用 .NET Framework 构建的 Windows CE 应用程序，该应用程序大约有 45 个表单。有 5 个“部分”可实现您想要的功能。该应用程序是 100% 全屏的，重要的是它不能最小化。
由于表单如此之多，因此很难跟踪关闭表单后应显示哪个表单。为此，我在显示表单所有者属性之前设置它，并在关闭表单时显示所有者属性。
我还被建议最好在应用程序加载时实例化所有表单，而不是处理它们以节省处理时间。我对此不太确定。
我的问题是，显示、隐藏表单（您希望任何 1 个表单始终全屏显示在前面）的最佳方法是什么？
I'm maintaining a Windows CE app built with the .NET Framework that has about 45 forms. There are 5 'sections' which lead to the function you want. The application is 100% full screen and it is important that it can't be minimized.
Since there are so many forms, it's difficult to keep track of which form should be displayed after one is closed. For this, I'm setting the form owner property before showing it, and showing the owner when closing it.
I've also been advised that it is best to instantiate all forms when the application loads, and not dispose them to save processing time. I'm not sure about this.
My question is, what is the best way to go about showing, hiding forms where you want any 1 form to be in front, full screen all time?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不会在应用程序启动时走实例化 45 个表单的路线。这将严重延长启动时间，并可能（如果不是可能）耗尽您的内存资源，所有这些都是为了提供您的用户可能不需要的功能。
在我的 WinMo 应用程序中，每个窗体都设计为处理相对较小的数据子集，因此启动时间仅限于数据库调用和将数据加载到窗体的控件中。通常，实例化这些表单之一并显示它所需的时间绝不会超过一两秒。
如果您的表单显示时间超过此时间，则可能是您的数据检索或将数据加载到表单控件中的方式存在问题（例如，您可能有一个自定义 gridview 控件，该控件完全呈现所有 300 行，即使一次只能看到 12 个）。如果您的数据太大，需要很长时间才能检索，那么很可能数据量远远超出了用户实际上可以交互的数据量。
我假设您提到“5 个部分”来了解用户需要去的地方，这意味着他们可能（最多）“深入”5 个级别以达到某些目的。如果您通过实例化每个表单并使用
ShowDialog显示下一个表单来实现此目的，则一次最多存在 5-6 个表单，这对于 . Net CF 应用程序（我一直这样做）。这样，您无需执行任何特殊操作来跟踪何时应显示哪个表单 - 您只需从任意位置打开一个表单，当该表单关闭时，您将自动返回到调用表单。您必须处理一些 z 顺序/任务管理器的奇怪问题，但它并不是特别复杂。在子窗体上调用
ShowDialog之前，将父窗体的Text属性设置为空白字符串，然后在ShowDialog< 后将其设置回窗体的原始标题。 /代码> 返回。这并不是绝对必要的，但在 Windows Mobile（至少版本 6 之前）中，所有打开的 .Net 表单（具有非空白 Text 属性）都会显示在“正在运行的程序”列表中，即使它们都来自同一个程序应用。我通常喜欢我的多表单应用程序看起来只是一个程序，因此我通常将每个表单的Text设置为应用程序的名称）。我还尝试了一个单一表单应用程序，它将每个 UI 部分实现为 UserControl 而不是 Form，然后创建并堆叠控件，就像创建和打开表单一样。这可行，但它是一种黑客行为，我不推荐它。表单有 Load 事件，而 UserControls 没有，这是主要问题。
I would not go the route of instantiating 45 forms when the application starts. This would severely lengthen the startup time and possibly (if not probably) exhaust your memory resources, all to provide functionality that your user may not even need.
In my WinMo applications, each form is designed to work with a relatively small subset of data, so the startup time is limited to database calls and loading the data into the form's controls. Typically, the time required to instantiate one of these forms and show it is never more than a second or two.
If your forms are taking longer than this to show, it's possible that there's a problem with your data retrieval or with the way the data is loaded into the form's controls (e.g. you might have a custom gridview control that fully renders all 300 rows even though only 12 are visible at one time). If your data is so large that it legitimately takes a long time to retrieve, chances are that's far more data than a user can practically interact with anyway.
I assume your mention of "5 sections" to get where the user needs to go means that they might (at a maximum) be "drilling down" 5 levels to something. If you implemented this by having each form instantiate and show the next form using
ShowDialog, you would have at most 5-6 forms in existence at any one time, which shouldn't be any problem for a .Net CF application (I do this all the time). This way, you don't have to do anything special to keep track of which form should be shown when - you just open a form from wherever, and when the form is closed you're automatically back to the calling form.There is some z-order/task manager weirdness that you have to deal with, but it's not especially complicated. Before calling
ShowDialogon the child form, you set the parent form'sTextproperty to a blank string, and then set it back to the form's original caption afterShowDialogreturns. This isn't strictly necessary, but in Windows Mobile (at least up to version 6) all open .Net forms (with a non-blank Text property) show up in the Running Programs list, even if they're all from the same application. I generally like my multi-form applications to appear to be just one program, so I usually set theTextof every form to the name of the application).I've also experimented with a single-form application that implements every piece of UI as a UserControl instead of a Form, and then creates and stacks the controls as if you were creating and opening forms. This works but it's a hack and I don't recommend it. Forms have a Load event and UserControls don't, which is the main problem.
该过程存在大量变量，因此不存在放之四海而皆准的方法。当然，加载所有表单最初意味着页面间导航速度很快，但它会使加载速度变慢，并且还会耗尽内存。
我的一般方法是使用框架 - 就我个人而言，我是 OpenNETCF IoC 框架 的粉丝，但后来我可能有偏见。
无论如何，您需要一个能够完成两件事的通用框架：
我对此做了一篇简单的框架文章 多年前的 MSDN。我更新了它以使用更纯粹的 MVC 分离和 IoC 框架最近。
这并不是说我的方法是唯一的方法，甚至是“正确”的方法。然而，我发现这是一种在桌面和设备上的多个部署中都取得成功的方法。
很难给您比这更细粒度的建议，因为我们真的不知道您的要求或限制是什么。如果您在内存和图形负载非常有限的慢速 ARM 设备上运行，我肯定会采用与具有千兆 RAM 的奔腾级 x86 嵌入式设备不同的方法（缓存、延迟加载等）。
编辑
你会发现 MusiGenesis 和我在攻击方式上的差异凸显了这样一个事实：没有“正确”的方法。正如我们所说，我正在为一个全屏嵌入式应用程序编写代码，该应用程序有 47 个视图，并且该项目包含一个且仅一个表单。他可能会使用 47 种不同的形态。两者都完成了工作。共同点是，我们都拥有某种形式的底层基础设施，可以处理了解顶层内容所需的所有内容。他依靠 ShowDialog 弹出 Forms 的本机 z 顺序。我依赖一个可以记住你来自哪里的自定义框架。
再次强调，这只是强调了没有对错之分——只要满足项目要求即可。
There are a whole load of variables to the process, so there's no one-size-fits-all methodology. Sure, loading all Forms initially means that inter-page navigation is fast, but it make load slower and it can also run you out of memory.
My general methodology is to use a framework - personally I'm a fan of the OpenNETCF IoC framework, but then I'm probably biased.
In any event, you need a general framework that does two things:
I did a simple framework article on this ages ago for MSDN. I updated it to use a more pure MVC separate and the IoC framework more recently.
This is not to say that my way is the only way, or even the "right" way. It is, however, a methodology that I've found to be successful in multiple deployments, both on the desktop and on devices.
It's difficult to give you more fine-grained suggestions than that becasue we really have no idea what your requirements or limitations are. If you're running on a slow ARM device with very limited memory and loads of graphics I'd certainly attack some things differently (caching, lazy loading, etc) than an pentium-class x86 embedded appliance with a gig of RAM.
EDIT
You'll see that the difference between how MusiGenesis and I would attack this highlights the fact that there is no "right" way. As we speak I'm doing code for a full-screen embedded app that has 47 views and the project contains one and only one Form. He would likely use 47 different Forms. Both get the job done. The commonality is that we both have some form of underlying infrastructure that deals with all of the goo required to know what's supposed to be on top. He relies on ShowDialog popping down the native z-order of Forms. I rely on a custom framework that remembers where you came from.
Again, this only highlights that there is no right or wrong - as long as it meets the project requirements.