GetControlType in CHECKBUTTON

[Rathinagiri]

In this context, I wish to show Roberto's intention from another thread.

viewtopic.php?f=12&t=52

Hi All,

From the start of HMG in early 2002, I've talked about the goal of 'hide operating system complexities'. Sometimes, I've used other words, but the idea is the same.

The release 2.5.5 is a good demostration of this concept.

Windows API includes two Combobox controls.

The standard combo and an enhanced version, capable of image handling.

IMHO, from an high level programmer point of view, must be only one combo in his toolbox, capable of handle images, if desired.

I could add a second combobox control (I could call it 'SuperCombo':) but IMHO it has no sense.

Instead that, the only thing that HMG programmers must care about, is that they have a new property called 'Image' for ComboBox control. That's all.

If you take a look at \hmg\source\c_combo.c file, you'll find two different functions to create a combo, depending on 'image' property content, but it is transparent for the HMG programmer.

There is lots of things required for Win32 API like IDs, ImageLists, Font objects, or pens that I've hide too.

This way, the programmer, can focus on the problem to solve via his application, instead the OS internals.

This is the xBase spirit. This is the HMG spirit too.

I think this may explain why we don't have difference in CheckBox and CheckButton inside HMG.

Also, I want you to please refer this post also about his intentions of HMG. IMHO, HMG has not deviated from this goal.

viewtopic.php?p=21#p21

[Rathinagiri]

See this small demo:

Code: Select all

#include <hmg.ch>

Function Main

   define window main at 0, 0 width 200 height 150 main
      define checkbox c1
         row 10
         col 10
         caption 'CheckBox'
         onchange findtype( 'c1' )
      end checkbox
      define checkbutton c2
         row 40
         col 10
         caption 'CheckButton'
         onchange findtype( 'c2' )
      end checkbutton
   end window
   main.center
   main.activate
Return

function findtype( cControl )
   if valtype( _HMG_Sysdata[ 7, GetControlIndex( cControl, 'main')] ) == 'A' // field
      msginfo( 'CheckButton' )
   else   
      msginfo( 'CheckBox' )
   endif   
return nil

Checkbutton Field is defined as an empty array. By checking that we can see whether it is a checkbox or checkbutton.

[Roberto Lopez]

Please, don't fix something that is not broken

OK, no problem.

Thanks.

At the time of my explanation I was very busy with work.

I'll clarify this topic a little more:

GetControlType() informs to the HMG library, about how a specific control must be processed and not about how a specific control looks like.

ie: TEXBOX control can report four different GetControlType() values:

- "NUMTEXT"
- "TEXT"
- "MASKEDTEXT"
- "CHARMASKTEXT"

Taking a deep look at this, You'll note that, none of them is "TEXTBOX"

Is this a GetControlType() malfunction?

No. It was designed that way

An example:

When you write

Code: Select all

<var> := <form>.<control>.value

It is translated to

Code: Select all

<var> := GetProperty(<form>,<control>,'Value')

Then (for most cases) GetProperty() calls the internal function _GetValue().

This function is responsible to give you the content of the 'value' property for almost all controls.

This is some of _GetValue() code:

Code: Select all

T = GetControlType (ControlName,ParentForm)

do case

    case T == "MASKEDTEXT" 

          some very complicated things are done here that only 
          are required when inputmask is not empty and datatype is numeric

    case T == "TEXT" .or. T == "EDIT" .or. T == "LABEL"  .or. ;
    T == "CHARMASKTEXT" .or. T == "RICHEDIT"

          the same process is useful for getting the value 
          for all these different controls
          including two textbox types: 
          standard and character datatype with inputmask

    case T == "NUMTEXT" 

          another different process. 
          This is for numeric datatype textbox with empty inputmask

So, as you see, giving a brief look at HMG sources is very clear that GetControlType() is not aimed to return the control type, as an user could understand it, but a reference to the way, that the control must be handled by HMG library internals.

A new (user-level) function aimed to return a control type name, that be meaningful for a final user, could be done, but it has nothing to do with GetControlType() internal function.

Finally...

I'm an ignorant... you know?

Yes... in fact... I'm ignorant about almost all knowledge that humanity had accumulated across thousands years...

I have only very little knowledge about very few things... HMG is one of those things.

[Roberto Lopez]

Post Data:

A false premise, based on false facts (based on lack of knowledge) drives to false conclusions, that could appear to be perfectly reasonable, if you assume that the premise is true

[Pablo César]

See this small demo:

Code: Select all

#include <hmg.ch>

Function Main

   define window main at 0, 0 width 200 height 150 main
      define checkbox c1
         row 10
         col 10
         caption 'CheckBox'
         onchange findtype( 'c1' )
      end checkbox
      define checkbutton c2
         row 40
         col 10
         caption 'CheckButton'
         onchange findtype( 'c2' )
      end checkbutton
   end window
   main.center
   main.activate
Return

function findtype( cControl )
   if valtype( _HMG_Sysdata[ 7, GetControlIndex( cControl, 'main')] ) == 'A' // field
      msginfo( 'CheckButton' )
   else   
      msginfo( 'CheckBox' )
   endif   
return nil

Checkbutton Field is defined as an empty array. By checking that we can see whether it is a checkbox or checkbutton.

Thank you Rathinagiri for your indication. I will use it.

When I found this, I acted as any one in good faith and propose as it should be: to report to the community. I have asked: "Am I wrong?" (because I was not knowing the reason for that strange behaviour) and I received an answer.
I think not all people have the same opinion. We are humans and we have our own personality. To let us give our opinion is a democracy and civilized way that we can find at any good forum. And this forum gives oportunity to express any concept and not always we have to agree. Isn´t it ?
When I disagreed as said: SORRY. I never thought that I could offend anyone...

I am still not agree with the solution given. I would prefer with the right info in its control creation. Sorry again. Not personal, only profisional.
At beginning says to avoid GetControlType because it is touching internal, but asking instead with other function GetControlIndex to be able at recognize when is CheckBox control or CheckButton control... I would ask to you: what´s difference?

But whatever be the real reason, I will not complain about this point. For me it is important to detect what I considered as fail because when I tried a "internal" function It should it gives me a real information. That´s the way I think and is unneeded to anybody feel bad with my opinion. That´s all.

And I wish the promisse that here wil be respect any opinion and keeping the chance for others to report whatever they find strange or badly function. Thi still remains?

And please gentleman, I would like you kindly close this topic. Because for me is already responded.

[srvet_claudio]

GetControlType() informs to the HMG library, about how a specific control must be processed and not about how a specific control looks like.

ie: TEXBOX control can report four different GetControlType() values:

- "NUMTEXT"
- "TEXT"
- "MASKEDTEXT"
- "CHARMASKTEXT"

Taking a deep look at this, You'll note that, none of them is "TEXTBOX"

Is this a GetControlType() malfunction?

No. It was designed that way

An example:

When you write

Code: Select all

<var> := <form>.<control>.value

It is translated to

Code: Select all

<var> := GetProperty(<form>,<control>,'Value')

Then (for most cases) GetProperty() calls the internal function _GetValue().

This function is responsible to give you the content of the 'value' property for almost all controls.

This is some of _GetValue() code:

Code: Select all

T = GetControlType (ControlName,ParentForm)

do case

    case T == "MASKEDTEXT" 

          some very complicated things are done here that only 
          are required when inputmask is not empty and datatype is numeric

    case T == "TEXT" .or. T == "EDIT" .or. T == "LABEL"  .or. ;
    T == "CHARMASKTEXT" .or. T == "RICHEDIT"

          the same process is useful for getting the value 
          for all these different controls
          including two textbox types: 
          standard and character datatype with inputmask

    case T == "NUMTEXT" 

          another different process. 
          This is for numeric datatype textbox with empty inputmask

So, as you see, giving a brief look at HMG sources is very clear that GetControlType() is not aimed to return the control type, as an user could understand it, but a reference to the way, that the control must be handled by HMG library internals.

A new (user-level) function aimed to return a control type name, that be meaningful for a final user, could be done, but it has nothing to do with GetControlType() internal function.

Thanks Roberto for this explanation.

[srvet_claudio]

I am still not agree with the solution given. I would prefer with the right info in its control creation. Sorry again. Not personal, only profisional.
At beginning says to avoid GetControlType because it is touching internal, but asking instead with other function GetControlIndex to be able at recognize when is CheckBox control or CheckButton control... I would ask to you: what´s difference?

Pablo this is nothing personal, in part the use and dissemination of many internal functions and low level solutions is my fault, I made use and abuse them in many demos and post here in the forum. Internal functions as its name says are just that, functions that should be used only for language development or otherwise should be created a public functions to do the work that the common user needs.

[gfilatov]

...
A new (user-level) function aimed to return a control type name, that be meaningful for a final user, could be done

Hi Roberto,

Thanks for this idea, Master

For example, it may be as follow

Code: Select all

*-----------------------------------------------------------------------------*
FUNCTION GetUserControlType ( ControlName, ParentForm )
*-----------------------------------------------------------------------------*
   LOCAL i, cRetName

   IF ( i := GetControlIndex ( ControlName, ParentForm ) ) == 0
      RETURN ''
   ENDIF

   cRetName := _HMG_aControlType [i]

   IF cRetName == 'CHECKBOX' .AND. ValType( _HMG_aControlPageMap [i] ) == 'A'
      cRetName := 'CHECKBUTTON'
   ELSEIF cRetName == 'COMBO'
      IF _HMG_aControlMiscData1 [i][1] == 0      // standard combo
         cRetName += 'BOX'
      ELSEIF _HMG_aControlMiscData1 [i][1] == 1  // extend combo
         cRetName += 'BOXEX'
      ENDIF
   ELSEIF "TEXT" $ cRetName .OR. "EDIT" $ cRetName .OR. "LIST" $ cRetName
      cRetName += 'BOX'
   ELSEIF "PICK" $ cRetName
      cRetName += 'ER'
   ELSEIF "MONTHCAL" $ cRetName
      cRetName += 'ENDAR'
   ENDIF

RETURN cRetName

Pablo, is it right now

[Roberto Lopez]

<...>
Thanks for this idea, Master
For example, it may be as follow

Thanks Grigory!

And...

I'll take this opportunity to say two things to you:

1. I really miss the times when we worked together... and...

2. You are a f*****g genius man...

Thanks Again (for all these years)!

[Pablo César]

Thank you Roberto and please accept my sincere apologies that I have been persistent and if by chance I have offended to you or anybody at something.

Thanks Claudio for your explaination, Grigory to materialize Roberto´s suggestion and Rathinagiri for previous example.

Before I writting this, I make my own test and I saw what Roberto tried to say. It´s not so simple as I have been thought.

In my experience, I have replaced _HMG_SYSDATA [1] [k] := "CHECKBOX" for _HMG_SYSDATA [1] [k] := "CHECKBUTTON" and I noted there comes many errors due this "CHECKBUTTON" is not declared as control type. Then requires for implementation and the idea to create an user function in parallel seems more easy and not prejudicative at new implementation. For it´s acceptable, but under my protest.

I´m trying most possible to avoid any access to _HMG_SYSDATA varmems following your advices, specially at one day the noble friend Claudio explained to me that should be safer and correct to access info via internal functions. Because one day, if some HMG structure changes: certainly I must to change my codes too.

Well done all this experience that bring to light for everybody where are our difficulties and challenges are in our appreciated HMG.