Welcome to the Project Developers' Table

[mrduck]

My first commit in hmg....

2010-10-30 13:48:00 UTC-0300 Francesco Perillo (<fperillo@gmail.com>)
* source/grid.prg
* Added ReturnValueOnEnter grid property, only with a SETGET method.
* samples/grid/demo_4.prg
* demo of ReturnValueOnEnter property and example of a little bug

[mrduck]

I try to demostrate a problem in combobox with onchange and items....

open samples/combobox/demo_3.prg, do this change:

Code: Select all

Define ComboBox Combo1
   Row 40
   Col 10
   Width 100
   Items {"Item 1","Item 2","Item 3","Item 4","Item 5"}
   value 3
   onChange {|| win1.t1.value = str(win1.combo1.value)}
   // OnDisplayChange win1.t1.value := win1.combo1.displayvalue
End ComboBox

OnDisplayChange doesn't work because this is not an editable combobox....

onChange sets t1.value to the combo1.value... what is the problem ? the problem is that when combo1 is create()d, onchange code block is assigned and when items/value are set, onchange codeblock is called.... but t1 is not yet create()d and so it was not added to win1 !!!!

If you change the line to:
onChange {|| t1.value = str(win1.combo1.value)}
it works ok, but now you are forced to have t1 variable available....

One "easy" change is to postpone onchange := after the set of value, so that onchange is not called but it is not good since that function may have some important side-effects...
I was thinking about adding one step to object creation:
now the first round is to create the hmg object,
the second run is at window:activate() when the Qt objects are created and all properties assigned
We should change this second run to just create the Qt object with basic properties, adding hmg objects to win, etc, then have a third run to assign the other properties, like items, value and all the onChange stuff....

[mrduck]

I want to give some more things to think on....

the callback functions of onLostFocus/onGotFocus are invoked without parameters, at least it seems to me... instead it would be usefull to have at least the QEvent parameter and, more interenstingly, the object they were invoked from !

Otherwise, how can I understand which object has invoked the call ? Am I missing something ?

[mrduck]

Code: Select all

2010-11-01 13:55 UTC-0300 Francesco Perillo (<fperillo@gmail.com>)
  * source/grid.prg
    * Added onInitCellEditor property
	It is called just after the grid has created the cell editor. It is
	useful if we need setup some other property on the cell... 
    oGrid1:onInitCellEditor := { |oGrid, oCellEditor, cColumnType| oCellEditor:onLostFocus := {|| something() } }

As an example:

I created a subclass of grid called myGrid, and changed oGrid1 from :grid():New() to :myGrid():New().

So I could do:
oGrid1:onInitCellEditor := { |oGrid, oCellEditor, cColumnType| oCellEditor:onLostFocus := {|| ::myNewMethod() } }

In this way ::myNewMethod has oGrid1 as its Self and from ::myNewMethod I can see all DATA and call all METHODs of Grid... if I'd call something() I'd lose connection to the grid or pass oGrid1 as parameter..

[Rathinagiri]

Thanks Francesco.

We have already ColumnWhen and ColumnValid events to call before entering and at the time of getting out the cell editor. This will also be helpful.

[Ricci]

hmg.4.bin.win.2010.11.02.exe

Can´t compile any source. Linker error.

[mrduck]

Sorry if I make this question that can seem really strange....

... is it really necessary to create the QT classes at window:activate() ?

I find difficulties using QLayout* .... does anybody use QLayout ?


does anybody use toolbar with other widgets in the form ?

[mrduck]

I find difficulties using QLayout* .... does anybody use QLayout ?

does anybody use toolbar with other widgets in the form ?

Fortunately it seems that Qt allows changing layout also at runtime, and so I change it in the on init callback function...

[Rathinagiri]

TO all hmg developers.

I want to inform you that signal/slot subsystem underwent some changes in how they report success/failure.

We should always check :connect return value.

A .T. means the connect went OK
A .F. means the connect failed: if you were connecting an event, .F. means that the same event is already connected: the system doesn't apply new setting but maintains the old. If you were connecting a signal, .F. means that Qt, after all the checks done on parameters, failed to do the connection.
In all other cases (non existant signal, wrong parameter types, etc) it will throw an RTE with a number. Each kind of error has a id value that is added to 1200. Duplicate event error was -3 and infact rathinagiri had a error number 1197 on screen... Now, as I said, -3 return .F. and not RTE.

In the last harbour, it is now safe (it returns .F.) to call :disconnect() on a not-connected event. It is better to reinstate the :disconnect before the :connect in hmg code...

Hi Francesco,

Does your words mean that

a) we need not add :disconnect() for signals
b) verify the return value of :connect() for all events before using :disconnect()?

[mrduck]

Hi Francesco,

Does your words mean that

a) we need not add :disconnect() for signals

After a certain commit, a :disconnect(9 of a not connected signal/event would RTE, so Roberto removed all the :disconnect(). It is no more necessary since now there is not a RTE but a return value of .F.

b) verify the return value of :connect() for all events before using :disconnect()?

No, just use :disconnect() and then :connect() if you are sure that you have to REPLACE the codeblock.


I want to tell you what happened to me. I was trying to add a event manager to the textbox created when editing a cell but the codeblock was never invoked... I the checked the return value of the :connect() and found it was .F. ... it was the signal that the event was already connected... and infact TEXTBOX always connects evento FocusOut...

A isConnected( signal/event) method is probably necessary to solve some cases, but checking the return value of :[dis]connect is ok at the moment