Close control disabled operated even if disabled

[RobertoBozzolo]

I have just faced a little problem that seems a bug to me.

If you have a panel and set a button as the close control, you can close the panel with the red cross in the corner even if the button is disabled!

It seems to me that in this case the panel should not be closed instead.

Attached a small project that reproduces the situation: run the project, press "Disable quit button" control, click on the cross in the upper right corner et voila: the panel closes! 

Tested up to CVI2013SP2

[Wolfgang]

Ehm, I do not understand why you call this a bug...

In my understanding you have one quit callback which can be called either from your quit button or from the close control of the panel. Disabling the button will only disable the first possibility of calling the callback from the button.

NI says: By default, the close control does not call anything. By defining a close control, you direct it to a particular callback function to quit your application.

So if you want to disable the panel close control you have to do this separately, see here

[RobertoBozzolo]

Let me give you an example: when you make modifications on a file inside CVI and press the close control you are asked whether you want to save or not; that is, the close control mirrors the behavior of File >> Exit function. If CVI would close without giving you a notice you'll brand it as a poor application, if not worse.

The same should apply in case the exit command is disabled.

Now you say this is to be programmmed by me? Ok, I can face it but I judge it a poor implementation.

Another example: if I have a check in quit callback for some event and prompt the user for a warning, this is mirrored by the close control (which I suppose simply calls the associated callback) without need for me to add a single line of code.

I know that I could simply test the state of the button inside its callback and return in case it is disabled, but it seems rare to me that you need to test whether the button is disabled inside the very same button callback! Let me say that if my code comes in somebody else's hands for maintenance they will call me insane and delete those lines, exposing to the risk of quitting the application without notice and maybe leaving an equipment in an uncontrolled situation!

That's why I consider this a bug.

[Wolfgang]

Roberto, I understand your arguments...

I just posted my understanding that the panel close button (the X) is an independent button with or without a callback, and the feature that its callback can be redirected to another control (which possibly is a quit button) and that I feel that this behavior is by design... (you could even call it more flexible )

Or, phrased differently, you disable the capability of the quit button to generate a callback, not the callback being called (and thus not the exit command as you call it) and thus the ability of the panel close button to call the callback still exists. By the way, how should the callback know that its button has been disabled?

For this reason I usually have a panel callback where I check for PANEL_CLOSE with the appropriate action (no reaction, for example...).

Maybe I just got too used to this behavior

[RobertoBozzolo]

I may possibly be too accustomed to my habits as well! Till now I have disabled the close button on the window title by default, but in search of a better conformance to Windows standard I recently decided to try enabling titlebar buttons and found some surprises, one of them being this one.

[RobertoBozzolo · Accepted solution]

In lack of additional comments, I post here the solution to this problem, which is quite simple: the control callback should be modified as follows:

int CVICALLBACK QuitCallback (int panel, int control, int event,
							  void *callbackData, int eventData1, int eventData2)
{
	int		dimmed;

	if (event != EVENT_COMMIT) return 0;

	GetCtrlAttribute (panel, control, ATTR_DIMMED, &dimmed);   // Test the state of the control
	if (!dimmed) QuitUserInterface (0);   // Terminate the program only if possible

	return 0;
}

This seems a misbehaviour to me, for this reason I posted a product suggestion: feel free to support it with kudos if you second my opinion.

[LuisG]

Hi Roberto,

Your rationale for preferring your suggested behavior makes sense. When the close control attribute was first added to CVI, I can easily imagine NI going along with your rationale and disabling the X button based on the state of the close control. Nevertheless, they made a different choice then, and even if we now all agreed with you that the alternative would have been preferrable, it's too late. Unless something is clearly a bug (and in my opinion, this isn't clearly a bug) we simply cannot intentionally change the runtime behavior of the library in this way. So, unfortunately, it's just too late.

Luis

[RobertoBozzolo]

Luis, I understand what you say, backward compatibility is valuable and should not be broken unless absolutely necessary.

I suppose at this point my suggestion in the idea exchange will be declined but at least add a specific note in CVI documentation so that everybody is warned about that.