1

我把自己搞糊涂了,到了无法回头的地步,觉得我的项目膨胀得太大了,无法跟上我目前的方式。

简而言之:

1) 有许多图形屏幕(窗口),每个屏幕都是在其自己的 .cpp 中定义的一个类,并附带一个带有公共和私有减速的 .h 标题。

2) 我正在使用 FLTK GUI 工具包,所以当我离开屏幕时,我会在其上调用“hide()”,我假设它会进行垃圾收集,然后我会创建一个新的实例,用于跟随任何屏幕。

我的问题是,如果一个屏幕(屏幕 A 可以调用它)创建另一个屏幕(屏幕 B),那么我必须在屏幕 A 中包含屏幕 B 的头文件,并在屏幕 A 的 .cpp 中创建一个指向屏幕 B 的全局指针。

IE。屏幕 A 的伪代码

#include "screenb.h"

ScreenB* screenb_ptr; // global

...
Bunch of Code, constructors, deconstructors, etc
...

void ScreenA::exit_and_make_screen_b()
{
    ScreenA.hide();
    screenb_ptr = new ScreenB();
}

这是最好的方法吗?我觉得它很草率(还有内存泄漏?),我应该有一个类似 .cpp/.h 的东西来跟踪一堆外部限定的指针;特别是有时我必须返回/前进屏幕(即可以从多个其他屏幕跳回主菜单屏幕)。任何建议表示赞赏!

4

2 回答 2

2

这里有一些建议:

  1. 创建一个包含所有屏幕内容的新头文件。然后你可以只包含这个头文件并捕获所有其他屏幕头文件。
  2. 您可能会考虑使用屏幕管理器来保存对屏幕的所有引用。然后,屏幕之间的导航由您的屏幕管理员负责处理所有引用和指针。这样您就不会将屏幕耦合在一起,而是通过一个共同的中介进行对话。

例如:

screenManager->NavigateScreen( SCREEN_USER_PROFILE );

您的所有屏幕都可以从一个基类继承,该基类包含一个指向屏幕管理器的指针(它们通过其构造函数获取或从静态单例实例中获取)。这样,您的所有屏幕都可以请求新的屏幕导航。

于 2011-03-23T16:04:20.753 回答
1

顺便说一句:我不完全确定 FLTK 的内存结构。隐藏屏幕可能根本不会删除内存,而只是隐藏窗口的 GUI 表示,允许您稍后以相同的状态再次打开它。

GUI 的一个好方法是模型-视图-控制器架构,您可以在其中有一个控制器来根据需要操作 GUI。

这将更多地表现为:

WindowManager wm;

void ScreenA::exit()
{
        wm.registerExit(screenb_ptr);
        wm.actOnExit();
}

或者一些类似的东西来让你的窗口有一个中央协调器。这允许:

  • 可插拔接口
  • 更好的组织
  • 防止错误
于 2011-03-23T16:08:38.410 回答