Heres a good idea

[mark smit]

Hi all,


I think I have a wish list item that we all could use. I would like to see PowerBasic add some keywords/features that allow get/set of ANY data type to and from edit controls.

control set byte cbhndl,%IDEDIT,n       (dim n as byte)
control get byte cbhndl,%IDEDIT to n    (dim n as byte)
control set long cbhndl,%IDEDIT,n       (dim n as long)
control get long cbhndl,%IDEDIT to n    (dim n as long)
control set string cbhndl,%IDEDIT,n$    (dim n as string)
control get string cbhndl,%IDEDIT to n$ (dim n as string)
control set asciiz cbhndl,%IDEDIT,n$    (dim n as asciiz)
control get asciiz cbhndl,%IDEDIT to n$ (dim n as asciiz)

dialog send cbhndl,%WM...
dialog post cbhndl,%WM... (need this one added)

dialog set text cbhndl,... (these also)
dialog get text cbhndl,...

Also I would like to see the following

callback function
end function

Replaced by...

callback
end callback

function
end function

I hope that makes sense.
------------------
Cheers



[This message has been edited by mark smit (edited January 29, 2001).]

[Gregery D Engle]

Mark,

I understand where you going, but this type of Typecasting would
be very confusing to the basic language. All these things that
you suggest would be very simple to accomplish via a byte ptr.

Just retrieve the value as a ASCIZZ * 255 (or however big you want)
and then create a byte array with all the information in it and
then make your own DataType.



------------------
-Greg

[Lance Edmonds]

I know that DIALOG POST and CONTROL POST are already on the wish list. I'll ask for some ticks against your name for these.

Since an edit control uses text as it's native data type (even for %ES_NUMBER controls), converting a numeric into a string (and vice-versa) is a simple matter of using FORMAT$() and VAL(), so I don't see any real significant advantage to adding a bunch of variable-class-specific statements to the compiler.

CONTROL GET|SET TEXT uses dynamic strings since there is little chance of an error occuring when retrieving a string of "unknown" length from an edit control. However, if an ASCIIZ string was specified, then it is possible the string could be truncated during the operation.

Therefore, this could cause unnecessary complications if edit control lengths were not "preset" to ensure that their length was limited to the size of the ASCIIZ string buffer (which would require an additional CONTROL SEND message earlier in the app).

By sticking with dynamic strings, you are free to copy the returned text data into any string or variable class you desire - this give the utmost flexibility to the programmer, for the cost of as little as one extra line of code after retrieving an edit control's string data.

However, maybe I'm missing something here... do you think you give us some specific instances where you think this sort of functionality would be useful, please? Thanks!

Finally, DIALOG GET|SET TEXT can be easily implemented with DIALOG SEND...%WM_GETTEXT|%WM_SETTEXT, or straight GetWindowText()|SetWindowText() API calls. However, for completeness, these would make good additions to the arsenal

{later} I just checked, and DIALOG GET TEXT and DIALOG SET TEXT are already on the wish list! I'll ask for some ticks against your name for these too.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[mark smit]

Lance,

I understand what your saying, It was after all just a wish. I'll post my routines in the source code forum so that others may have them.

What about the DIALOG SET/GET TEXT for DDT? some ticks for that as well?


------------------
Cheers

[Lance Edmonds]

Yup!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>