Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » TopWindow&PopUp, TrayIcon » BUG? EditInt / PromptOK not functioning as thought?
BUG? EditInt / PromptOK not functioning as thought? [message #48076] Sun, 14 May 2017 20:29 Go to next message
ptkacz is currently offline  ptkacz
Messages: 36
Registered: March 2017
Member
When an EditInt field is populated with a valid value (i.e. 0..999; 4 allowable digits), the PromptOK box displays as expected upon the clicking of a submit button.

When an EditInt field is populated with a number greater than the max allowable value, the field turns red, and the incorrect PromptOK dialog box displays. In order to get the PromptOK window to display with the correct message, the close window button needs to be selected.

What's going on here? Code listed below.


Peter


Bug1.lay
LAYOUT(Bug1Layout, 84, 60)
	ITEM(EditInt, editField, Max(999).Min(0).MaxChars(4).LeftPosZ(8, 64).TopPosZ(8, 19))
	ITEM(Button, submitButton, SetLabel(t_("submit")).LeftPosZ(8, 64).TopPosZ(36, 15))
END_LAYOUT



Bug1.h
#ifndef _Bug1_Bug1_h
#define _Bug1_Bug1_h

#include <CtrlLib/CtrlLib.h>

using namespace Upp;

#define LAYOUTFILE <Bug1/Bug1.lay>
#include <CtrlCore/lay.h>

class Bug1 : public WithBug1Layout<TopWindow> {
public:
	typedef Bug1 CLASSNAME;
	Bug1();
	void buttonClicked(void);
};
#endif



main.cpp
#include "Bug1.h"

Bug1::Bug1()
{
	CtrlLayout(*this, "Bug1 Window");
	
    submitButton << THISBACK(buttonClicked);
}


void Bug1::buttonClicked(void) {
	int value = editField;
	
	if( value > 999 ) {
		PromptOK("Number too big!");
		return;
	}
	else
		PromptOK("Number accepted!");
}


GUI_APP_MAIN
{
	Bug1().Run();
}
Re: BUG? EditInt / PromptOK not functioning as thought? [message #48077 is a reply to message #48076] Sun, 14 May 2017 21:17 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 466
Registered: September 2012
Location: Poland, Kraków
Senior Member
Hello,

It is classical example of "Working as design bug". When you use Min and Max attribute of EditField you don't need to control the validation of the field value. It will happen automatically and if the number is wrong it will mark the field with red co and hook at the end of window life time. I am not 100% certain when the prompt will be displayed, but i based on my previous experience.

So if you want to disable this validation - simply remove Min and Max from the EditField layout property.

Sincerely,
Klugier


Ultimate++ - one framework to rule them all.
Re: BUG? EditInt / PromptOK not functioning as thought? [message #48079 is a reply to message #48077] Sun, 14 May 2017 21:33 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1740
Registered: August 2008
Location: Czech Republic
Senior Veteran

Hi Peter,

I haven't check the code, but if I remember it correctly the check you perform should actually look like this:
	if (IsNull(value)) {
		PromptOK("Invalid number!");
		return;
	}
	else
		PromptOK("Number accepted!");


The edit field returns Null value when it is empty, invalid or outside of the allowed range.

Best regards,
Honza
Re: BUG? EditInt / PromptOK not functioning as thought? [message #48081 is a reply to message #48079] Mon, 15 May 2017 05:21 Go to previous messageGo to next message
ptkacz is currently offline  ptkacz
Messages: 36
Registered: March 2017
Member
Thanks guys.

The IsNull(editField) works.

There's still a problem though. As long as the value that's populated within the edit field is outside the specified range on the edit field, one has to correct the problem, or one can't exit out of the application when selecting the close application button (i.e. 'x'). Selection of the close application button results in a pop-up window displaying the message, "Number must be between 0 and 999".

The message is kind of vague since it doesn't indicate which field has the issue.

Wonder what happens where there are multiple issues?


Peter

[Updated on: Mon, 15 May 2017 05:22]

Report message to a moderator

Re: BUG? EditInt / PromptOK not functioning as thought? [message #48087 is a reply to message #48081] Mon, 15 May 2017 20:37 Go to previous messageGo to next message
Zbych is currently offline  Zbych
Messages: 255
Registered: July 2009
Experienced Member
ptkacz wrote on Mon, 15 May 2017 05:21
As long as the value that's populated within the edit field is outside the specified range on the edit field, one has to correct the problem, or one can't exit out of the application when selecting the close application button (i.e. 'x')

I must admit that this behaviour is really annoying, you can set Rejector to IDCANCEL in window constructor to disable it:
Bug1::Bug1()
{
	Rejector(*this, IDCANCEL);//<-----------------------
	CtrlLayout(*this, "Bug1 Window");
	submitButton << THISBACK(buttonClicked);
}


[Updated on: Mon, 15 May 2017 20:42]

Report message to a moderator

Re: BUG? EditInt / PromptOK not functioning as thought? [message #48092 is a reply to message #48076] Tue, 16 May 2017 05:40 Go to previous messageGo to next message
ptkacz is currently offline  ptkacz
Messages: 36
Registered: March 2017
Member
That's interesting, the Rejector.

I'm guessing that the functionality should really work by popping up the message when the field loses focus? Similar to how the field turns red when validation is applied against it.

How about instead, make it such that if a field entry is in error, a tool tip becomes enabled on the field. So that when the mouse hovers over the highlighted edit field, a tool tip displays indicating what the issue is? A simpler solution?

Here's a screen shot of the issue:

index.php?t=getfile&id=5286&private=0

[Updated on: Tue, 16 May 2017 05:51]

Report message to a moderator

Re: BUG? EditInt / PromptOK not functioning as thought? [message #48341 is a reply to message #48092] Sat, 24 June 2017 16:00 Go to previous message
mirek is currently offline  mirek
Messages: 11082
Registered: November 2005
Ultimate Member
ptkacz wrote on Tue, 16 May 2017 05:40
That's interesting, the Rejector.

I'm guessing that the functionality should really work by popping up the message when the field loses focus? Similar to how the field turns red when validation is applied against it.


I do not think that would be good - as general solution. Sometimes the error is a result of combination of values, so associating it with value of single field is probably not a good idea.

In general, the 'annoying behaviour' is mostly the result default settings.

In U++, you dialog can be 'breaked' (no errors displayed, nothing else is done), 'accepted' (errors are checked and dialog does not exit if there are errors found) or 'rejected' (no errors displayed AND dialog is restored to values before Run). See http://www.ultimatepp.org/srcdoc$CtrlLib$Tutorial$en-us.html ch. 18, 20

Now the problem is with the default settings of WhenClose callback that gets invoked by clicking "window close" [X] button. Default is to call TopWindow::Close virtual method, which is defined this way:

void TopWindow::DefaultBreak()
{
	if(FindAction(IDCANCEL) || close_rejects)
		RejectBreak(IDCANCEL);
	else
	if(FindAction(IDNO))
		RejectBreak(IDNO);
	else
	if(FindAction(IDEXIT))
		AcceptBreak(IDEXIT);
	else
	if(FindAction(IDYES))
		AcceptBreak(IDYES);
	else
		AcceptBreak(IDOK);
}


That means it reacts on presence of different types of 'breakers' and if there is none defined, defaults to 'accept'. However, fix is simple, all you need is to override Close or set WhenClose to something else, e.g.

app.WhenClose = [=] { app.Break(); };



Previous Topic: Linux dual monitor: Not showing a TopWindow on the task bar
Goto Forum:
  


Current Time: Fri Jul 28 14:41:46 CEST 2017

Total time taken to generate the page: 0.00678 seconds