Lazarus

Programming => LCL => Topic started by: jamie on April 26, 2020, 04:28:50 pm

Title: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: jamie on April 26, 2020, 04:28:50 pm
like it says

 I don't know how long this has been this way but I used to be able to set a combobox at runtime to READOnly or switch it back to not READonly..

 I understand the argument that Delphi has removed that property but do we need
to repeat their mistakes ?

 As it is now, it has styles that are not even in Delphi's implementation , this would be the styles property..

 So, I don't always want OwnerDraw styles, I want to be able to simply lock the edit box when needed and unlock it later..

 So I just open an old APP, and noticed it no longer works for that feature  ,  I can't lock it at will..

 So I resorted to using a GetComboBoxInfo function and the rest is history..

Like I said, do we really need to follow someone if they are going to jump off the cliff ?
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: Thaddy on April 26, 2020, 04:49:12 pm
You can use disabled/enabled instead?
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: wp on April 26, 2020, 05:02:07 pm
What do you understand as "ReadOnly"? Unable to type in the edit field of the combobox? Or unable to select another item from the dropdown? Or unable to change anything at all?

Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: Thaddy on April 26, 2020, 05:13:12 pm
[No change at all: Set Enabled to false. This will give a "disabled" look, though.
I consider this a good thing, because it gives a form of feedback to the user that editing is not possible.
AFAIK he can not even tab to it when disabled.

See "About Face" by Alan Cooper. Best book on user interface design.
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: jamie on April 26, 2020, 05:14:55 pm
Well I guess you cant see it from where I sit..


 I don't want to change the style in mid flight, have you see what happens to the control when you do that ?

 I have code where I can at any point lock the EDIT box and it does not effect the control what so ever...

 And I don't like the greyed out effect...

 I just implemented the SendMessage(EdithandleOfCOmbo, EM_SETREADONLY, Ture/false, 0);

 it works perfectly that way. At least on that app but this will only work in windows.

 Changing the style isn't the answer, it causes hardship in mid flight.

EDIT
 While we're at it, the TComboBoxEX seems to be useless, I don't remember it being this crippled...
  Most if not all of the autocomplete functions don't work, do nothing etc..
 It seems like a waste of real-estate in IDE.
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: Thaddy on April 26, 2020, 05:19:55 pm
Confusing the user by your interpretation of a "consistent" look is not a good idea: you have to inform the user in some - visual - way that the field can not be edited. That's my point.
Such shortsightedness will only overload your help desk.

The grayed out look was designed with just that in mind:inform the user.
But that look can be changed with ownerdraw in whatever you find less intrusive.
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: jamie on April 26, 2020, 05:27:33 pm
there is no confusion, attempts to type are caught at the Keypress where the status is checked and alerts the user with a little popup message to please wait or current status as to why, the message can vary..

 The reason is that while the user is typing in the current content is sent to another busy section of code, in that code is some ProcessMessage calls, the edit box needs to be locked at the time this takes place because it gets busy at times, this also thread related.

 It simply needs to be working for this reason and others I can think of.

 I don't like the idea of resetting the text back to the previous content while a busy state is at hand because that causes the control to flicker and do other things I have to catch.

 No, this approach I have used many times and it's a working model..

 I wish they would consider this so it would work cross platform... otherwise If I ever port this over its going to be a threaded mess
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: wp on April 26, 2020, 05:32:13 pm
Changing the style isn't the answer, it causes hardship in mid flight.
Then post a feature request to the bug tracker and assign it to Ondrej Pokorny, refer to r55243 where he deprecated the ReadOnly property and explain your concerns (I think, however, that the ReadOnly always has been achieved by changing the style).

While we're at it, the TComboBoxEX seems to be useless, I don't remember it being this crippled...
  Most if not all of the autocomplete functions don't work, do nothing etc..
 It seems like a waste of real-estate in IDE.
Nothing will change when you write this in the middle of a discussion which will not be seen by the relevant people. File a bug report, describe what is not working, add a sample project, and hopefully somebody will look at it.
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: jamie on April 26, 2020, 06:14:18 pm
The app I am doing the ReadOnly := False in is one that I successfully converted from an old running copy of Delphi with a lot of pain involved .

 I had thought that it was working but this would explain whey we have been getting random garbage errors when user is typing in stuff. I never saw the alert come up
because I test the READonly property for its current state.

 Today I just put in a the Sendmessage and ran some test and I no longer see the randomness of this issue here at the test desk..

 I'll post a bug report ..

 Thanks
Title: Re: ReadOnly property for Combo boxes needs to be re-enabled..
Post by: jamie on April 26, 2020, 06:34:34 pm
as for the EX version, I guess this isn't new..

https://forum.lazarus.freepascal.org/index.php?topic=31067.0
TinyPortal © 2005-2018