Behavior of Disabled and Read-only Fields

Discussions specific to Team Developer 5.1.

Behavior of Disabled and Read-only Fields

Postby caa » Fri Mar 27, 2009 6:25 am

Hello,

We've been getting quite a few requests for changing behavior of read only and disabled fields. Please find, attached, a description of the spec that we're going to be adhering to from now on.

Although we did not meet this level of behavior for SP5, we are doing so for SP6.

In general, we are being backwards compatible with TD 4.2, with one exception: in TD 4.2, you were able to set the foreground color of a disabled field. In TD 5.1 and later you will not be able to do that. Instead a disabled field is grayed out.

Please let me know if you have any questions.
You do not have the required permissions to view the files attached to this post.
caa
 

Re: Behavior of Disabled and Read-only Fields

Postby Dave Rabelink » Fri Mar 27, 2009 4:52 pm

One question.

Will it be possible to change the background and text color for disabled fields programatically ?
In many cases disabled fields are used for text info on forms (without border).

What is missing now is to use text label fields using the field template name.

Code: Select all
Form Window: frmMain
   Contents
      Background Text: bkgdText
   Message Actions
      On SAM_CreateComplete
         ! The next line throws a compile error "Assignment of different types"
         Set bkgdText = "Hahaha"
         !
         ! The next line throws a compile error "Reference to 'MyValue' is not within an object having a value"
         Call SalSetWindowText( bkgdText, "Hahaha" )
         !
         ! The next line throws a compile error "Reference to 'MyValue' is not within an object having a value"
         Call SalColorSet( bkgdText, COLOR_IndexWindowText, COLOR_Red )
         !
         ! The next line throws a compile error "Reference to 'MyValue' is not within an object having a value"
         Call SalSetWindowLoc( bkgdText, 1, 1 )



So, having a more complete set of features to manipulate text fields, in most cases the issue for disabled fields may be solved.
But even in other cases, disabled fields should have the ability to control appearance.

Other feature request for background text fields: Support for handling messages like SAM_Click, Sam_Create etc.
Regards,
Dave Rabelink

Image
Articles on Team Developer Wiki
Download samples from TD Sample Vault

Image
Go forward! Come join the TD, SqlBase & TDMobile community on
Team Developer Community Forum
User avatar
Dave Rabelink
 
Posts: 1655
Joined: Sat Feb 17, 2007 12:01 am
Location: Gouda, The Netherlands

Re: Behavior of Disabled and Read-only Fields

Postby lrcuess » Sun Mar 29, 2009 3:13 pm

Hi,

I fully support the request for beeing able to use the Background Text template name as Window Handle in Sal-functions.
And also the second wish about controlling the appearance of disabled Datafields, as we also used them as "Easy modifyable Background Texts", which don't fit into the new GUI design because of their non-gradient-background-color.

Thanks!
Max
Markus Eßmayr
RACON Software GmbH
http://www.racon.at
User avatar
lrcuess
 
Posts: 1163
Joined: Mon May 07, 2007 5:58 am
Location: Linz, Austria

Re: Behavior of Disabled and Read-only Fields

Postby Didiman » Sun Mar 29, 2009 3:36 pm

I also support this, and please can you change the copy behaviour of background text. The copy of an existing field should get a name like "copy of ..." or something like this instead of just the same name as the original has. I often copy background text fields and surely forget to rename the copy.
Andreas Neugebauer
Head of IT
AZUL Kaffee GmbH & Co. KG
Bremen / Germany
User avatar
Didiman
 
Posts: 167
Joined: Sat Jan 05, 2008 3:50 am

Re: Behavior of Disabled and Read-only Fields

Postby apaula » Wed Apr 01, 2009 9:25 am

Hi Dave,

Will it be possible to change the background and text color for disabled fields programatically ?


We're keeping the behavior of TD4.2 for both Disabled and Read-only ("Editable=No") fields.

In TD4.2 it's possible to change the foreground and background colors of Read-only datafields programmatically. It's also possible to change the background color of disabled (SalDisableWindow) fields, not the foreground in this case.

This is slightly different from what Chris mentioned earlier in this thread. We've just modified the attached PDF to accommodate this so we're fully compatible with 4.2.

Don't hesitate to get back to me if you feel that it's not the case.

Thanks,
You do not have the required permissions to view the files attached to this post.
Ana
---
Director of Global Customer Support
apaula
Site Admin
 
Posts: 1164
Joined: Wed Feb 14, 2007 2:22 pm
Location: UK

Re: Behavior of Disabled and Read-only Fields

Postby PeterFr » Thu Apr 02, 2009 5:25 pm

Dear Ana,

the reading of a disabled datafield with SalDisableWindow is very hard for our customer.
E.g. with TD151Sp6
Image
or now with TD51Sp5
Image

So we found out Call SalSendMsg( df1, EM_SETREADONLY, 1, 0 ) is working better for us with TD151
After enabling the datafiled (which works perfect in TD151) in TD51 the text color is not correct:
Image
Image

Mike was so kind and created a defect for this (TD-5937).

Please, if text colors could not be changed for Disabled datafield (so far my understanding is right)
please correct TD-5937. This is for us a major issue why we can't move to TD51.
Thank you very much!
Best Regards
Peter
--
Best Regards
Peter
PeterFr
 
Posts: 101
Joined: Thu Dec 20, 2007 8:58 am
Location: Munich

Re: Behavior of Disabled and Read-only Fields

Postby apaula » Fri Apr 03, 2009 12:19 am

Hi Peter,

Yes, TD-5937 is corrected in SP6.
Thanks for the follow up.

Cheers,
Ana
---
Director of Global Customer Support
apaula
Site Admin
 
Posts: 1164
Joined: Wed Feb 14, 2007 2:22 pm
Location: UK

Re: Behavior of Disabled and Read-only Fields

Postby mike » Wed Apr 15, 2009 9:23 pm

This is nice but for those people out there that still want the same behaviour add the following two classes and function and you get the same:
Code: Select all
Function: EditableKeys
   Description: Detect if wParam key in a WM_KEYDOWN is an editable key or not
   Returns
      Boolean:
   Parameters
      Number: vk
   Static Variables
   Local variables
   Actions
      Return vk!=0x09 and vk!=0x24 and vk!=0x25 and vk!=0x27 and vk!=0x23

General Window Class: clsNoinputWindow
   Description:
   Derived From
   Class Variables
   Instance Variables
      Boolean: bNoInput
   Functions
   Message Actions
      On WM_CHAR
         If bNoInput and EditableKeys(wParam)
            Return 1
      On WM_KEYDOWN
         If bNoInput and EditableKeys(wParam)
            Return 0
         If wParam=VK_F12
            Call SalModalDialog(dlgAscii,hWndNULL,hWndItem)
      On WM_SYSCHAR
         If bNoInput and EditableKeys(wParam)
            Return 0
      On WM_CUT
         If bNoInput
            Return 0
      On WM_PASTE
         If bNoInput
            Return 0
      On WM_CLEAR
         If bNoInput
            Return 0
General Window Class: clsNofocusWindow
   Description: Refuse focus
   Derived From
   Class Variables
   Instance Variables
      Boolean: bNofocus
   Functions
   Message Actions
      On WM_SETFOCUS
         If bNofocus
            Return 0

useage:
On SAM_Create
  set bNoFocus=TRUE                 !disables the focus on the data or multiline field so no copy is possible
On SAM_Create
  set bNoInput=TRUE                  !disables the ability to change code in there but does allow copy
mike
 
Posts: 13
Joined: Wed Apr 15, 2009 9:15 pm

Re: Behavior of Disabled and Read-only Fields

Postby JaakkoTerhonen » Tue Sep 22, 2009 1:52 am

Hi!

I have TD5.1/SP6 and I noticed that if a field is disabled on design time by setting "Editable=No" the function SalIsWindowEnabled now returns TRUE :(

I think this is totally wrong, the field is not "enabled" (even if it is possible to select & copy text from it).

Documentation says about SalIsWindowEnabled:

Determines whether a window is enabled for mouse _and keyboard input_.
Parameters
hWndEnabled Window Handle. The handle (or name) of a window.
Return Value
bOk is TRUE if hWndEnabled is enabled and FALSE if hWndEnabled is not enabled or is not a valid handle.

I have code relying on the result of call to SalIsWindowEnabled and I am in big trouble. Please tell me what (you or I) should do ?


Thanks & best regards,

Jaakko Terhonen
JaakkoTerhonen
 
Posts: 33
Joined: Fri Jan 25, 2008 9:20 am

Re: Behavior of Disabled and Read-only Fields

Postby apaula » Tue Sep 22, 2009 2:30 am

Hi Jaakko,

Support will work to reproduce and let you know the results as soon as possible.

Thanks for your report,
Ana
---
Director of Global Customer Support
apaula
Site Admin
 
Posts: 1164
Joined: Wed Feb 14, 2007 2:22 pm
Location: UK

Re: Behavior of Disabled and Read-only Fields

Postby herve » Wed Sep 23, 2009 4:37 pm

Hello,

In order to answer to your last question:

"I have TD5.1/SP6 and I noticed that if a field is disabled on design time by setting "Editable=No" the function SalIsWindowEnabled now returns TRUE
I think this is totally wrong, the field is not "enabled" (even if it is possible to select & copy text from it)."


Find attached a simple application.
There are two fileds which one with Editable= No.

when I click the button I get True which seems to be right.
Let me know what you expect and complete the test case to be sure I understand your request.


Regards

Hervé
You do not have the required permissions to view the files attached to this post.
herve
 

Re: Behavior of Disabled and Read-only Fields

Postby herve » Wed Sep 23, 2009 4:57 pm

Sorry, I realized that I test the window Handle and not the field Handle.

Yes the two tests return true:

On SAM_Click
If SalIsWindowEnabled(df1)
Call SalMessageBox('df1 Is Enabled','Test editable = no ',MB_Ok|MB_IconAsterisk)

If SalIsWindowEnabled(df2)
Call SalMessageBox('df2 Is Enabled','Test editable = yes ',MB_Ok|MB_IconAsterisk)

I am going to test with TD 4.2.

Hervé
herve
 

Re: Behavior of Disabled and Read-only Fields

Postby herve » Wed Sep 23, 2009 5:09 pm

Hello,

TD 5.1 + SP6 and TD 4.2 have the same behaviour regading SalIsWindowEnabled.

Regards

Hervé
herve
 

Re: Behavior of Disabled and Read-only Fields

Postby JaakkoTerhonen » Fri Sep 25, 2009 10:19 pm

Well,

that does not make me any happier: I upgraded from TD1.5.1 where SalIsWindowEnabled IMHO behaved correctly.

May I ask what is the logic in considering a field having "Editable = No" to be an "enabled" field ?

And could You please advise me how can I determine if a field has "Editable=No" ? I do need to know that !!!

Best,
Jaakko
JaakkoTerhonen
 
Posts: 33
Joined: Fri Jan 25, 2008 9:20 am

Re: Behavior of Disabled and Read-only Fields

Postby Dave Rabelink » Sat Sep 26, 2009 5:54 am

In Windows, there is a difference between the terms Enabled/Disabled and Editable/NonEditable (=ReadOnly).

An enabled window (field) receives input from mouse and keyboard. So it registers clicks and keyboard actions.
A disabled window does not, so it is not possible to select the content (or part of it) and it does not register the tab key so a disabled field will not be part
of the tab sequence on a form.

You can change the contents of an editable field while a non-editable field, the content is locked (read-only). But, non-editable fields can be selected, content can be copied and it does take part of the tab sequence.

Up until TD2000, TD named the attribute EDITABLE=YES/NO incorrectly. It did not set the editable attribute, but in fact it set the enabled attribute.
By setting a datafield to editable=NO, TD disabled the field. Which was in fact wrong.

The call

Code: Select all
SalIsWindowEnabled


Did in fact return FALSE when the attribute editable=NO, because TD disabled the field

Up from TD2000 (???) Gupta changed it to the correct attribute to be in line with standard Windows. So setting editable=NO will not disable the field, but set the field to non-editable (as it should).
That is the reason why SalIsWindowEnabled returns TRUE on the editable=NO setting. The window is still enabled, but it is set to readonly.

To determine if a field is set to non-editable, you can use

Code: Select all
! Number: ES_READONLY      = 0x0800

VisWinGetStyle( dfField ) & ES_READONLY = ES_READONLY


If you are porting from a pre-TD2000 version and you want to keep the old functionality (editable=NO means DISABLED) you can set the TD environment to be compatible.

You can read more on this here:
http://tdwiki.daverabelink.net/index.ph ... datafields

Hope this clarifies things.
Regards,
Dave Rabelink

Image
Articles on Team Developer Wiki
Download samples from TD Sample Vault

Image
Go forward! Come join the TD, SqlBase & TDMobile community on
Team Developer Community Forum
User avatar
Dave Rabelink
 
Posts: 1655
Joined: Sat Feb 17, 2007 12:01 am
Location: Gouda, The Netherlands

Next

Return to Team Developer 5.1

Who is online

Users browsing this forum: No registered users and 1 guest

cron