HMGforum.com

Also, pressing Esc key could be taken as 'Cancel'

Rathinagiri wrote:Also, pressing Esc key could be taken as 'Cancel'

It would be a problem because InputWindow already have an array parameter for HotKeys.
At common use of InputWindow it would be superimposed same action key...

Unless that a fourth parameter (for grids propose only) could it accepts aHotKeys in place (see option D listed below)

So it could be call InputWindow like these:

1. InputWindow() (without any parameter). It will detect by itself all grid properties.
2. InputWindow(<cParentWindowName>,<cControlName>) (both parameters as regular character type variables).
3. InputWindow(<cParentWindowName>,<cControlName>,<anWidths>) (two character variables and one numeric array). This array will contain the total of columns with its width's size of each.
4. InputWindow(<cParentWindowName>,<cControlName>,<anWidths>,<aHotKeys>) (two character variables, one numeric array and one composite array). This last array could contains the all parameters for Hot Key.
   For example: { { 0, VK_ESCAPE, {|| ThisWindow.Release() }, { { 0, VK_F1, {|| My_Help() } }

So in this way, you would do like this, for example:

abHotKey:={ { 0, VK_ESCAPE, {|| ThisWindow.Release() } }

ON DBLCLICK MyReplace(InputWindow(<cParentWindowName>,<cControlName>,<anWidths>,abHotKey))

or this:

ON DBLCLICK MyReplace(InputWindow(,,,abHotKey))

Remember that all these parameters listed here for InputWindow to Grids, are optional, not mandatory.

I'm talking to bring HotKey parameter as 4th one, just to make easier for users.
By itself InputIndow accepts aHotKey as 9th parameter already.
But it's making hard to do it like this: InputWindow(,,,,,,,, aHotKeys)

What's your opinion ? Better to re-stablish a fourth parameter as nineth for aHotKeys ? (valid for grids propose, of course)

---

Rathinagiri wrote:Also, you can get the column justification definition using _HMG_SYSDATA [ 37 ] [nIdx] You can right align the textboxes wherever required.

There are three alignment types for grids:

1. GRID_JTFY_LEFT
2. GRID_JTFY_RIGHT
3. GRID_JTFY_CENTER

For TextBoxes and also DatePickers, right and left alignments are no problem.
But the question is when is setted to GRID_JTFY_CENTER in on column grid.
In TextBoxes we have not this ES_CENTER edit style.
So is it posible to use SendMessage with ES_CENTER ? (I thinks it's available at control definition only)
To use ES_CENTER in C:\MiniGUI\SAMPLES\Applications\WinErrors

See this attached file WinError: Let me know if you have any idea for GRID_JTFY_CENTER cases.TextBox, it's posible.

Best Regards,

Pablo César wrote:For TextBoxes and also DatePickers, right and left alignments are no problem.

Just for clarifying about right alignment in DatePickers.

When we pass RightAlign as TRUE. The drop-down month calendar will be right-aligned with the control. Like this:
Instead of left-aligned, which is the default, will be like this:
Anyway, it was implemented at InputWIndow too.

Hi all,

ChangeLog - Version 1.12:

1. Fixed when using keyboard and press enter: row and col of grid were not real.
2. Added column justification to the right making TextBoxes and DatePicker to be aligned to the right.
3. Allowed 4th parameter for aHotKeys definitions, in place of 9th parameter.

Text in "Some considerations" in this message was re-edited.

<Attached source code file was removed because there is a newer version released more ahead of this message in this same topic>

Rgds

Pablo,

Center justification is not required, I think. Only right align is enough.

Regarding aHotKeys, it is better to keep in 9th place and if omitted, by default, pressing Esc shall cancel the grid edit.

Hi Rathi, good morning

Rathinagiri wrote:Center justification is not required, I think.

If would it be required, TextBoxes should it have a new style option: ES_CENTER

Only right align is enough.

I've alredy implemented yesterday.

Regarding aHotKeys, it is better to keep in 9th place

I've done by 4th and tell you why. Some parameters in IputWIndow when used to Grids are not useable ones.
Then after be considered the 4th parameter as aHotKeys, the rest of parameters became easier to understand and use all the rest parameters too (of course as optional). So in this way, have been open two more ways for calling InputWIndow to Grids.

..if omitted, by default, pressing Esc shall cancel the grid edit

Ok, I'll add this checking by default, good idea !
I also liked much to have it in my apps.

I've been waiting your return yesterday but you were out and I needed to keep going on... so I've done what I believed to be better.

I hope you understand that.

B.Rgds

ChangeLog - Version 1.13:

1. Esc hotkey defined by default to cancel the grid edit
2. Third item of "Expected new interesting features" in this message, regarding "Simulates same property of EditOption from grid to be applyied for others controls like as: TextBox and EditBox"
   
   Just added a new function for working at any TEXT (similar grid control) in HMG library.

<Attached source code file was removed because there is a newer version released more ahead of this message in this same topic>

I hope you enjoy !

Pablo,

I use columnwidth as 0 for hidden columns (for example, we can hide the itemcode from the user).

1. When I tried to use inputwindow2() with the last column as 0, nothing is shown for any field.
2. When I tried to use inputwindow2() with any other column as 0, that column data is also shown.

Hi Rathi,

I found what's happening when columnWidth is equal to 0 (zero).

Please note following line at InputWindow.prg:

If "GRID" $ cControlType .and. (GetProperty(cForm,cGrid,"ColumnWIDTH",nPos) = 0 .or. (i=1 .and. Len(_HMG_SYSDATA [ 14 ] [nIdx]) > 0))

and please replace for this:

If "GRID" $ cControlType .and. (GetProperty(cForm,cGrid,"ColumnWIDTH",i) = 0 .or. (i=1 .and. Len(_HMG_SYSDATA [ 14 ] [nIdx]) > 0))

Thank you for reporting.

Rathinagiri wrote:I use columnwidth as 0 for hidden columns (for example, we can hide the itemcode from the user).

Rathi let me know one thing. What's your opinion about hidden control in InputWindow in these cases ?

IMO, should it skip the column when ColumnWidth as 0.
Not be hidden and occupy more one place in InputWindow.
Because, users can defined one or more than one columnwidth as 0 then the displaying fields will let an empty space like this:
Columns 2 and 3 with ColumnWidth as 0 (zero). In this case are hidden at InputWindow.
I think if is hidden and not be editable better not taking place in InputWindow.
Aesthetically speaking is not good these empty spaces at editing (grids edition).
Is it Right for you in this way ?

What's your opinion in this ?