[Commodity] handling commodity window/interface

[mateusz_s]

Hi,
I am not sure how to handle commodity window/interface.

Commodity can have its window that can be show/hide
In the Exchange app.
Should I create and open new window
When the Commodity is created and then just
Show/hide it?

Or the window should be created/closed
Each time the user clicks show/hide in the Exchange app.?

[thomas]

When the user chooses hide, you should close the window and ideally release all GUI-related resources.

The reason is that while the GUI is hidden, the user expects to be able to close the Workbench screen (for example for a screen mode change). This is not possible if you keep the window open and only hide it.

Also the new functions HideWindow and ShowWindow are only available in OS 3.2+. So if you don't want to reach only half or less of the community, you should avoid these functions.

While the GUI is hidden it should not consume any resources, so if possible you should close all external libraries, classes and so on.

[a/b]

Originally Posted by thomas

While the GUI is hidden it should not consume any resources, so if possible you should close all external libraries, classes and so on.

What an outdated approach. You should always statically link all boost and cef libraries at a minimum, and don't forget denuvo (it's not for games only!1!11!). If they can't handle it, they should buy new hardware.

[mateusz_s]

Originally Posted by thomas

When the user chooses hide, you should close the window and ideally release all GUI-related resources.

The reason is that while the GUI is hidden, the user expects to be able to close the Workbench screen (for example for a screen mode change). This is not possible if you keep the window open and only hide it.

Also the new functions HideWindow and ShowWindow are only available in OS 3.2+. So if you don't want to reach only half or less of the community, you should avoid these functions.

While the GUI is hidden it should not consume any resources, so if possible you should close all external libraries, classes and so on.

@thomas thank you for answer - Yes that makes sense.

[mateusz_s]

I forgot to ask one more question.

The commodity has its own main loop that process messages in it.
If I want to create and show the window - its also need to have its own
message loop?

I am not sure how to combine that two loops?
Maybe you have some examples in C?

In my case - my commodity checks something each couple of seconds and stores the result.
But optionally I would also update that result in the window.

[thomas]

You should build your program around one main loop with one Wait() instruction which waits for events from all parts of your app.

It could look like this:

BOOL cont = TRUE;

do	{
	ULONG winsig   = 1L << win->UserPort->mp_SigBit;
	ULONG timersig = 1L << timereq->tr_node.io_Message.mn_ReplyPort->mp_SigBit;
	ULONG cxsig    = 1L << cxport->mp_SigBit;

	ULONG sigs_received = Wait (winsig | timersig | cxsig | SIGBREAKF_CTRL_C);

	if (sigs_received & SIGBREAKF_CTRL_C)
		{
		cont = FALSE;
		}

	if (sigs_received & timersig)
		{
		WaitIO (timereq);
		...
		timereq->tr_node.io_Command = TR_ADDREQUEST;
		SendIO (timereq);
		}

	if (sigs_received & winsig)
		{
		struct IntuiMessage *imsg;
		while ((imsg = GetMsg (win->UserPort)))
			{
			switch (imsg->Class)
				{
				...
				}
			ReplyMsg (imsg);
			}
		}


	if (sigs_received & cxsig)
		{
		CxMsg *cxmsg;
		while ((cxmsg = GetMsg (cxport)))
			{
			switch (CxMsgType (cxmsg))
				{
				...
				}
			ReplyMsg (cxmsg);
			}
		}
	}
while (cont);

You can safely set one of the signals to 0 if that part of your app is currently not active.

For example if you change the code to

ULONG winsig   = (win != NULL ? 1L << win->UserPort->mp_SigBit : 0);

then the window handling code will not be executed if the window is closed. You only have to take care that you set the window pointer (win) to NULL when you close the window.

[mateusz_s]

Originally Posted by thomas

You should build your program around one main loop with one Wait() instruction which waits for events from all parts of your app.

It could look like this:

BOOL cont = TRUE;

do	{
	ULONG winsig   = 1L << win->UserPort->mp_SigBit;
	ULONG timersig = 1L << timereq->tr_node.io_Message.mn_ReplyPort->mp_SigBit;
	ULONG cxsig    = 1L << cxport->mp_SigBit;

	ULONG sigs_received = Wait (winsig | timersig | cxsig | SIGBREAKF_CTRL_C);

	if (sigs_received & SIGBREAKF_CTRL_C)
		{
		cont = FALSE;
		}

	if (sigs_received & timersig)
		{
		WaitIO (timereq);
		...
		timereq->tr_node.io_Command = TR_ADDREQUEST;
		SendIO (timereq);
		}

	if (sigs_received & winsig)
		{
		struct IntuiMessage *imsg;
		while ((imsg = GetMsg (win->UserPort)))
			{
			switch (imsg->Class)
				{
				...
				}
			ReplyMsg (imsg);
			}
		}


	if (sigs_received & cxsig)
		{
		CxMsg *cxmsg;
		while ((cxmsg = GetMsg (cxport)))
			{
			switch (CxMsgType (cxmsg))
				{
				...
				}
			ReplyMsg (cxmsg);
			}
		}
	}
while (cont);

You can safely set one of the signals to 0 if that part of your app is currently not active.

For example if you change the code to

ULONG winsig   = (win != NULL ? 1L << win->UserPort->mp_SigBit : 0);

then the window handling code will not be executed if the window is closed. You only have to take care that you set the window pointer (win) to NULL when you close the window.

Great - many thanks @thomas again -