DATEGET - new date only input class

[Ricci]

Datepicker is great for getting dates because of it´s calender widget.
But if you want to allow the user to leave date fields empty, datepicker is unuseful because it doesn´t allow empty dates.
So I created this simple input class.

Code: Select all

DEFINE DATEGET oDateGet
   ROW 10; COL 10
   WIDTH  100; HEIGHT 20
   VALUE <dValue>
END DATEGET 

The input mask is created automatically by the programs SET DATE setting. Maxlength is set automatically.
Validation: if the input is an invalid date, the last value is restored when leaving the DATEGET control.

Alignment, CaretPos, OnEnter, PassWord and the basic methods (FONT, DISABLEDFONTCOLOR, VISIBLE, ...) are supported.

[mrduck]

Good !

Now the final touch: pressing F2 opens a calendar widget....

Datepicker is great for getting dates because of it´s calender widget.
But if you want to allow the user to leave date fields empty, datepicker is unuseful because it doesn´t allow empty dates.
So I created this simple input class.

Code: Select all

DEFINE DATEGET oDateGet
   ROW 10; COL 10
   WIDTH  100; HEIGHT 20
   VALUE <dValue>
END DATEGET 

The input mask is created automatically by the programs SET DATE setting. Maxlength is set automatically.
Validation: if the input is an invalid date, the last value is restored when leaving the DATEGET control.

Alignment, CaretPos, OnEnter, PassWord and the basic methods (FONT, DISABLEDFONTCOLOR, VISIBLE, ...) are supported.

[Ricci]

Now the final touch: pressing F2 opens a calendar widget....

Hmmmm ..... I use F2 to fill input fields with the current date.

The the user should assign a key of his choice for this function. Should that be set as global property at program start (for all DATEGET) or one definition per control?

[mrduck]

Now the final touch: pressing F2 opens a calendar widget....

Hmmmm ..... I use F2 to fill input fields with the current date.

The the user should assign a key of his choice for this function. Should that be set as global property at program start (for all DATEGET) or one definition per control?

Correct ! user-assigned, program wide key for popup.

Thanks

[Rathinagiri]

Wow! It is very nice Ricci.

[l3whmg]

Hi Ricci.
I think your jobs with GETDATE, NUMGETC is great, but I don't understand why you don't choose to improve (or change if it's not good) current TEXTBOX object.
On the other hand, I don't understand this:

I could not wait until TEXTBOX will work as it should be so I decided to create a stripped Textbox class

on this topic http://hmgforum.com/viewtopic.php?f=32&t=2237

Many people don't write anythink about my commit regarding TEXTBOX: so, I think it works. No people have thought to make changes to the code: so, I think it works.

When I start to rewrite TEXTBOX, I found different solution for numeric data, date and so on in very simple way rather than current/previous HMG4 textbox pov (I remember to everyone that previous version it doesn't work), but I choose to find a solution in agreement with HMG3 style and follow HMG4: one object textbox with inputmask for different data type.

One object it's not a good solution? Ok, but we must remove TEXTBOX object and work on different objects. As I write to you and to MrDuck there is not problem related with HMG3 command because they know the data type, so we can call the right OOP object. But we will have different appearances between OOP and command; a little example:
With OOP we will write "WITH OBJECT NUMGETC" with command we will write "DEFINE TEXTBOX"
With OOP we will write "WITH OBJECT GETDATE" with command we will write "DEFINE TEXTBOX"

But the most important question now is: what object must be used and improved by volunteers?
Otherwise, if I were a newbe what I can choose or understand? TEXTBOX (for every data type but only with command style) or GETDATE or NUMGETC with OOP syntax?
And we spent energy in most directions and HMG4 will not complete.

I repeat: Ricci your work is great, but I don't understand where are problems to use/improve current objects or to change pov.

AFAIK, null date work with current TEXTBOX as with DATEPICKER or there are problems?

@Rathi but not only: why did you not write anything about my TEXTBOX commit? It should not be considered? It is totally useless? I have the previous version: in a minute I can overwrite current textbox.

Best regards.

p.s. Related with "F2" I think can be better a CHECKBUTTON (or similar) near the field: when I click on it calendar will appear. Function keys can be used by program.
Cheers

[Ricci]

Luigi, you spend a lot of work into Textbox to make it HMG3/CLIPPER compatible. This work is necessary for the HMG4 project. Because of handling text, numeric and date data in one control the Textbox code has gotten very complex - too complex for me. And I understand that there a problems since the code is in development.

You know I´m working in my orchid program and want to make my users possible to use the next version. But since some weeks I could not build a stable and user friendly version because of the changes in Textbox. So I decided to build some simple controls for myself - free from the bounds of HMG3 compatibility. And it´s also a good way for me to learn.

Many people don't write anythink about my commit regarding TEXTBOX: so, I think it works. No people have thought to make changes to the code: so, I think it works.

Perhaps I´m the only one who is using HMG4 in a real program?
Seems like a lot of people are watching the project but no one has the courage (or the time) to use it.

[Ricci]

AFAIK, null date work with current TEXTBOX as with DATEPICKER or there are problems?

Using :shownone() to display an empty DATEPICKER is possible (hoping that everyone understand "None") but editing it is uncomfortable:
- first you have to use the up-key to get a editable date (than it shows 15.09.1752) or you have to use the calendar
- how to empty a Datepicker field when editing?

Btw.: My DateGet class will get a calendar with a button soon, than it will look and feel nearly like the Datepicker but work with QLineEdit in the background.

[Rathinagiri]

@Rathi but not only: why did you not write anything about my TEXTBOX commit? It should not be considered? It is totally useless? I have the previous version: in a minute I can overwrite current textbox.

Hi Luigi,

I didn't write about TextBox because it is a standard feature. It doesn't in any way mean that it is not worth.

[Ricci]

Now the final touch: pressing F2 opens a calendar widget....

Related with "F2" I think can be better a CHECKBUTTON (or similar) near the field: when I click on it calendar will appear.

I had no problem adding a pushbutton into the DateGet control to open a calendar widget when clicked but ...

... no chance to close the widget when it lose it´s focus. But that´s a precondition: the calendar should close when the user choose a day or click outside (lost focus).

The calendar itself is a compound widget which has no focus, so QEvent_FocusOut is not working. Harbour doesn´t support the method :children() to get the children of the calendar widget and look for their focus signal.

My second try was to create a pop-up window with the calendar widget in it. If the window looses his focus it should close. And I want to suppress title and borders of this window by using :TitleBar(.F.). But without titlebar the window has no focus and again I can´t control if the user clicked outside this window.

Maybe time to give up. I spend a lot of time in it but even the limits of Harbour or Qt destroy my work.