About 'Values' to be Preserved and Mr. Spock :)

Moderator: Rathinagiri

User avatar
sudip
Posts: 1444
Joined: Sat Mar 07, 2009 11:52 am
Location: Kolkata, WB, India
Has thanked: 4 times

Re: About 'Values' to be Preserved and Mr. Spock :)

Post by sudip » Mon Apr 27, 2009 9:50 am

Hello Roberto,

Thank you very much for explaining Win32 in "less than 20 pages" :) I always believe that one who "really" knows can explain complex thing "simple" :)

Regarding ON CHANGE, at first I liked Grigory's suggestion. Very interesting and helps backward compatibility. But, as only 7 controls have this problem, we must think in another way.

In that case I like Rathi's suggestion:-
Rathinagiri wrote:Now for the backward compatibility, IMHO, you can freeze this version and go for the next version, so that, the new version have cleared this.
With best regards.

Sudip
With best regards,
Sudip

User avatar
mol
Posts: 2801
Joined: Thu Sep 11, 2008 5:31 am
Location: Myszków, Poland
Has thanked: 112 times
Been thanked: 52 times
Contact:

Post by mol » Mon Apr 27, 2009 9:55 am

I think, an idea of Grigory Filatov is very interesting. Of course, for all controls.
It will give us full control when value of control is changed by programmer, not interactively by user.

Marek

User avatar
Roberto Lopez
HMG Founder
Posts: 3897
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 13 times
Been thanked: 132 times

Post by Roberto Lopez » Mon Apr 27, 2009 12:33 pm

rathinagiri wrote:Ya. Crystal clear.

And I know now, how much efforts you had put forth to achieve simplicity. Hats off man. Bravo.
It was not my intention praise myself... sorry :)

Regards,

Roberto.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
Roberto Lopez
HMG Founder
Posts: 3897
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 13 times
Been thanked: 132 times

Post by Roberto Lopez » Mon Apr 27, 2009 12:48 pm

rathinagiri wrote:Now for the backward compatibility, IMHO, you can freeze this version and go for the next version, so that, the new version have cleared this.
My experience in HMG demonstrated that when changes are made (specially, big ones) we must expect some 'bug waves' related with that changes.

ie: WAIT WINDOW had created a (die hard) bug related to focus on app activation.

It is possible that 'CellNavigation' give us some other little problem yet.

So, I agree with you and I'm doing exactly that (I've not included these changes in 2.8.8).

IMHO, the only way to have stable releases is to limit the number of changes for each release, and wait for new changes until the new code was extensively tested by the users, fixed and stable enough.

If you don't do that, you'll have a library in a permanent state of flux that will be never stable/reliable enough

Regards,

Roberto.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
Roberto Lopez
HMG Founder
Posts: 3897
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 13 times
Been thanked: 132 times

Post by Roberto Lopez » Mon Apr 27, 2009 1:06 pm

sudip wrote:Hello Roberto,

Thank you very much for explaining Win32 in "less than 20 pages" :) I always believe that one who "really" knows can explain complex thing "simple" :)
I've been a pupil from long long time and a teacher during 20 years.

I've knew two kinds of teachers.

- The ones that talk using a difficult language and expressions only to show the pupils how much they know.

- The ones that uses simple metaphors and examples, a plain language and are not afraid to admit that they have not answers for all questions.

The first class are usually bad persons with serious self-estimation problems and (of course) bad teachers.

I've tried to fit on the other class (but is not easy :))

Regards,

Roberto.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
sudip
Posts: 1444
Joined: Sat Mar 07, 2009 11:52 am
Location: Kolkata, WB, India
Has thanked: 4 times

Post by sudip » Mon Apr 27, 2009 2:47 pm

Roberto Lopez wrote: I've been a pupil from long long time and a teacher during 20 years.

I've knew two kinds of teachers.

- The ones that talk using a difficult language and expressions only to show the pupils how much they know.

- The ones that uses simple metaphors and examples, a plain language and are not afraid to admit that they have not answers for all questions.

The first class are usually bad persons with serious self-estimation problems and (of course) bad teachers.

I've tried to fit on the other class (but is not easy :))
I want to say that all most respected "teachers" in the world - Jesus, Mahammad, Buddha and many others - all taught very "complex" thing "simple". :)

With best regards.

Sudip
With best regards,
Sudip

User avatar
Roberto Lopez
HMG Founder
Posts: 3897
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 13 times
Been thanked: 132 times

Post by Roberto Lopez » Mon Apr 27, 2009 3:04 pm

sudip wrote: I want to say that all most respected "teachers" in the world - Jesus, Mahammad, Buddha and many others - all taught very "complex" thing "simple". :)
Absolutely true!

Regards,

Roberto.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
AdrianSB
Posts: 17
Joined: Thu Feb 26, 2009 7:38 pm
Location: Argentina - Quilmes

Post by AdrianSB » Mon Apr 27, 2009 7:23 pm

Hola a todos!!

No estoy seguro de entender exactamente el tema. ¿ Estamos hablando de establecer una acción durante la definición de un control y luego modificarla en tiempo de ejecución ?

De ser así, mi humilde análisis es el siguiente:

Si existen controles que lo permiten es porque deben almacenar la acción asignada durante su definición como una propiedad que puede ser modificada en tiempo de ejecución. Los controles que no lo permiten deben estar haciéndolo en una propiedad o variable local que es la realmente utilizada en el evento sin volver a obtener el valor de la acción programada desde la propiedad utilizada durante la definición.

Creo que una posible solución sería implementar una extensión de las clases de los controles con el error, que evalúen siempre la acción programada en la propiedad utilizada en la definición.

Saludos !!

GOOGLE TRANSLATION

Hello everybody!

I am not sure I understand exactly the issue. Are we talking about setting an action for the definition of a control and then modify it at runtime?

If so, my humble analysis is as follows:

If there are controls that allow it to be stored is allocated for the action defined as a property that can be modified at runtime. The controls that do not allow it to be so in a local variable or property that is actually used in the event without returning to get the value of the action program since the property used for the definition.

I think one possible solution would be to implement an extension of the classes of checks and error, to evaluate if the planned action on the property used in the definition.

Greetings!

User avatar
sudip
Posts: 1444
Joined: Sat Mar 07, 2009 11:52 am
Location: Kolkata, WB, India
Has thanked: 4 times

Post by sudip » Tue Apr 28, 2009 4:09 am

Hello Adrian,
I am not sure I understand exactly the issue. Are we talking about setting an action for the definition of a control and then modify it at runtime?
I want to say some words regarding this with my LIMITED KNOWLEDGE :)

IMHO, we can change a control during runtime in two ways :-
1) Interactive chane (e.g., when we write in a textbox)
2) Programmatically change (e.g., Form_1.Textbox_1.Value := "Hello World")

In both cases OnChange event of the control "control" should fire. But, in reality, there are 7 controls whose OnChange event don't fire when there values are changed programatically!

So, Roberto wants to discuss whether we should "debug" those 7 controls' behavior or we should maintain their status as it is.

In the first case some good software already created with Minigui will face problem. And in the other case those 7 controls will behave "differently" than others!

Please rectify me if I am wrong. So that I can have a clear conception :)

With best regards.

Sudip
With best regards,
Sudip

User avatar
AdrianSB
Posts: 17
Joined: Thu Feb 26, 2009 7:38 pm
Location: Argentina - Quilmes

Post by AdrianSB » Tue Apr 28, 2009 8:37 am

Hola Sudip !!

Lamento si he creado confusión al respecto. Mi interpretación del tema que estaban tratando fue la de evaluar la posibilidad de modificar, en tiempo de ejecución, la acción asignada al evento ON CHANGE en la definición de un control.

Ejemplo:

// Defino el control cuando se crea la interfaz de usuario
DEFINE WINDOW oWnd
DEFINE CONTROL oControl
ON CHANGE ( Accion_01() ) ...
END CONTROL
END WINDOW

// Modifico el valor en tiempo de ejecución como modo de parametrización de la interfaz
FUNCTION CONTEXTO_EJECUCION( _cContexto )

// ¿ Existe la propiedad .bOnChange ?
If _cContexto == "01"
oWnd.oControl. :?: := {||Accion_01()}
Else
oWnd.oControl. :?: := {||Accion_02()}
EndIf

RETURN

Analizando el problema según tu descripción, mi humilde opinión es:

Un evento, es comprendido por todos como la respuesta a una determinada acción. Si llegamos al consenso de especificar que un evento se encuentra directamente asociado a la acción del operador sobre el control ( presión de una tecla, presión de un botón del mause, desplazamiento del puntero del mause, etc. ), entonces queda claro, para mí, que debe seguir existiendo la diferencia de comportamiento ya que la asignación programática de un nuevo valor no es una acción del usuario y brinda mayor libertad al programador.

Ejemplo:
// Genero un nuevo valor procesando el ingresado por el usuario
oWnd.oControl.Value := Formateo_Contenido(oWnd.oControl.value)

CONCLUSION

Creo que en ambas interpretaciones del tema hay un punto en común: Debería implementarse una propiedad bOnChange

INTERPRETACION 01
...
If _cContexto == "01"
oWnd.oControl.bOnChange := {||Accion_01()}
Else
oWnd.oControl.bOnChange := {||Accion_02()}
EndIf
...

INTERPRETACION 02

...
// Modifico el contenido de la propiedad
oWnd.oControl.Value := Formateo_Contenido(oWnd.oControl.value)
// Fuerzo la ejecución del evento CHANGE sólo en los casos donde lo necesite
uResultado := Eval(oWnd.oControl.bOnChange)
...

Saludos !!


GOOGLE TRANSLATION

Sudip Hello!

I am sorry if I have created confusion on the matter. My interpretation of the theme they were trying was to evaluate the possibility of modifying, at runtime, the action assigned to event ON CHANGE in the definition of a control.

Example:

/ / Set control when creating the user interface
DEFINE WINDOW oWnd
DEFINE CONTROL oControl
ON CHANGE (Accion_01 ()) ...
END CONTROL
END WINDOW

/ / Changing the value at runtime as a way of parametrization of the interface
FUNCTION CONTEXTO_EJECUCION (_cContexto)

/ / Does the property. BOnChange?
If _cContexto == "01"
oWnd.oControl. ::: = (| | Accion_01 ())
Else
oWnd.oControl. ::: = (| | Accion_02 ())
ENDIF

RETURN

Analyzing the problem as your description, my humble opinion is:

An event, it is understood by all as a response to a particular action. If we reach the consensus to specify that an event is directly associated with the action of the operator in the control (pressing a key, pressing a mouse button, moving the mouse pointer, etc..), Then it is clear to me which should remain the difference in behavior since the program allocation of a new value is not a user action and provides greater freedom to the programmer.

Example:
/ / Generate a new value to process the input by the user
oWnd.oControl.Value: = Formateo_Contenido (oWnd.oControl.value)

CONCLUSION

I think that both interpretations of the theme there is one point in common: a property should be implemented bOnChange

Interpretation 01
...
If _cContexto == "01"
oWnd.oControl.bOnChange: = (| | Accion_01 ())
Else
oWnd.oControl.bOnChange: = (| | Accion_02 ())
ENDIF
...

Interpretation 02

...
/ / Modifying the contents of the property
oWnd.oControl.Value: = Formateo_Contenido (oWnd.oControl.value)
/ / Force the implementation of the Change event only in cases where you need it
uResultado: = Eval (oWnd.oControl.bOnChange)
...

Greetings!

Post Reply