就我的感觉而言，我正处于为我的应用程序做出重要的高级设计决策的阶段。在过去的几天（！）中，我一直在进行一些调查，测试，发现展示广告并重新启动的周期...由于我过去也曾多次从别人的工作中受益，所以我想我花时间分享自己的成果。也许可以帮助某人节省一些时间。或从那里的专家那里得到一些宝贵的反馈意见：-)。我在下面回答我自己的问题。我欢迎评论，尤其是警告：-)问候德克
我预计一旦实现所有功能后，会有许多不同的屏幕（希望用户仍然发现它很容易使用。 UX合一。总是。它似乎。因此，我将使用许多小步骤（屏幕），如向导样式，而不是一个“复杂的”大屏幕。因此，单个主窗体和带有“某些”选项卡的tabcontrol似乎不是一个不错的选择:-)。想象一下，您有50个包含许多组件的选项卡，并且有一天您加载了该项目，并且IDE不再希望通过一些异常的错误消息来呈现该表单...-是的，我见过它...其他人了吗？ :-)。但是，如何为所有这些屏幕建模？对我来说，最合理的尝试是使用框架。仅1种主要形式并加载mainform可用客户区域中的框架（同时在mainform上具有一些总体静态控件）。框架轻巧并且可以调整大小，如果需要，可以在align不是'client'时轻松放置它们。当用户单击相关组件或返回时，我使用框架的自我管理堆栈来添加/删除（推送/弹出）框架。因此，我只创建了一次，然后使框架可见或不可见，重新使用实例以提高性能。也许以后我应该验证/管理内存消耗。但这会产生一致的外观。我开心。不幸的是...您需要保持时尚。如果造型（在设计时）很重要（或者可能如此，谁知道这一点），那么框架就没有严重的缺点。简而言之，它们不是在设计时设置样式的。我现在不确定是否对我来说很重要，但是它给我一种非常不舒服的感觉。我们与Borland进行RAD视觉开发已有30年了，很抱歉，Embarcadero，产品..so，真的吗？我尝试了许多建议的解决方法，但未能成功使它们样式化为表单（是的，如果您复制现有样式，请重命名它们并使用自己的样式名在框架组件上，然后它们以某种方式（但不是完全）样式化。因此，我认为这根本不值得（肮脏的）努力。但是，是的，很奇怪，显然可以从技术上完成一些样式设计，因此令人感到沮丧的是，没有合适的``默认''逻辑可以使用例如（单个）主要形式的样式书。无论如何..当您需要使用明显使用底层``本机''平台控件的组件时，会发生另一个（间接）问题。 tweb浏览器。它以“最重要”的行为闻名，并且隐藏了它重叠的所有其他组件（至少在现在为止-似乎有望与其他z顺序修复程序一起解决...）。当我找到twebbrowser时，本地和远程视频的唯一可靠，灵活的视频播放器（！）（顺便说一句，这也花了我一些时间来找出困难的方法...），因此使用它绝对是必须的为了我。然后，此问题实际上是一个热门话题（在应用程序中非常不专业...）。当浏览器可以滚动屏幕时（例如隐藏我的主工具栏），我确实找到了一种“解决方法”，这是使它不可见并显示文本，而当再次充满它时它将返回可见。视图...我知道，很丑，但是你能做什么..？回到绘图板....上面的结果是，对于我而言，别无选择，然后无论如何都使用表单...并尝试解决其缺点（最重要的是：它们始终在移动设备上全屏显示。）。Sofar，我已完成以下操作，我使用主窗体，并且还在每个屏幕上使用窗体（不要忘记将其从自动创建的项目源中删除...）。我仍然使用堆栈来管理用户屏幕流。不使它们全屏显示的“技巧”是将其设置为borderstyle（无边框）和formstyle（弹出式）弹出框。因此，从视觉上看，它们现在的行为就像框架：将它们加载到主窗体的可用客户区域中（尽管要正确放置它们有点棘手……）。而且我没有注意到使用“大量”表单组件会带来任何性能问题。另外...宾果，作为一个非常受欢迎的副作用，这也解决了twebbrowser问题！这些表单上的Web浏览器在移动时不再隐藏主表单！我开心。备注：尽管将样式书放在单独的数据模块上感觉更好，但是我发现将样式书放在主窗体上时会更加稳定。所以，是的，所有其他形式都“使用”在界面级别链接样式书的主要形式。我认为这并不算太糟，因为我所有的“子”形式实际上都由主形式控制并且在逻辑上是依赖的。它们不是独立的可重用表单...只要主表单或其他表单需要访问另一表单逻辑（例如加载它），就会在实现的``使用''部分中添加它。（显然，主表单具有这些唯一的选择，否则我们有循环单位引用）。到目前为止还不错，但是.....（哦，是的...）。弹出式表单由TScreen以特殊方式处理。如果发生某些特定事件（例如转到其他应用并返回），它们会自动关闭。可能还有更多的事情也可能导致这种情况。在移动设备上，您不能像在Windows上那样在当前应用程序屏幕之外单击，但仍然我认为我需要对其进行“处理”，否则我的用户突然会再次看到启动屏幕（唯一的非弹出窗口）。幸运的是，这次表单的确是“繁重的” :-)，我在onclosequery中添加了它们永远不应该关闭的内容（CanClose = false，因此不再需要自动弹出窗口关闭）！而且我的应用程序使用隐藏/显示过程来处理它们是否可见。 （隐藏和关闭之间存在微妙的区别-没有自由-但对我来说，它是完美的）。表单均归主表单所有，并一起释放。他们之前没有真正关闭似乎没有问题。但是无论如何，您都可以在“ onclosequery”中使用自己的逻辑来处理该问题，并只允许它们在最后关闭。到目前为止一切顺利，但是.....文档中有关于弹出式窗体的评论，这让我有点担心，“弹出式窗体永远不会处于活动状态”。尽管除了“ onactivate”事件从未触发（但我的popupforms可以获取焦点，可以对其进行编辑等）之外，我没有遇到任何有关沙发的特定信息，但我担心它会困扰我一些意想不到的观点。因此，在我的最终设计中，我颠倒了这两种窗体的用法：每个应用程序屏幕都有正常的窗体，并且我使用了1个“弹出”工具栏窗体，并将其放置在屏幕导航中。因此，现在我的表单是“正常”表单，并且现在仅使用一种特殊的弹出表单，这限制了风险。而且，是的，当滚动离开屏幕时，这些标准格式的Web浏览器也不会与我的浮动弹出工具栏重叠！我开心。
我希望我在所有这些方面都感到最后的惊喜，但是可以肯定的是，我会及时通知你。由于表格确实很重，我相信我将能够优雅地解决任何其他问题：-)。我开心。毕竟。一旦有了最终的稳定代码，我将发布一些摘要。
我希望这会对某些人做出自己的设计选择有所帮助。