Hi,
Hobbyest programmer here, can anyone tell me what has replaced CellBorderBottomAt (and the rest) in the new ListBox for API2.
Thanks
Barry
This is a good question. Anyone?
out of curiosity I checked the docs… the only thing pertained to cell borders I saw was:
http://documentation.xojo.com/api/user_interface/desktop/desktoplistbox.html.CellBorderColor
I thought maybe it might be there… But that is only about color and seems to assume all 4 sides have to be the same color… And the example code is for CellCheckBoxStateAt so it is clear as mud !!!
Don’t know about the actual listbox border capabilities, but the documentation certainly needs more work… Maybe setting the borders is there, but just not documented?
-karen
1 Like
can you use own paint?
https://documentation.xojo.com/api/user_interface/desktop/desktoplistbox.html.PaintCellBackground
Yes, I noticed the documentation was wrong too, I meant too mention that in the original post.
The sample code has been replaced with correct sample code. Thanks for pointing this out. The page was likely duplicated but the sample code not replaced. It’s fixed now.
So is the a way to set the Cell borders (as well as column borders) individually?
For me that has always been very important for end User UI. If not that is a HUGE loss in functionality IMO… I have used that for almost every listbox in every app I’ve written one the years!
If the answer is to draw you own CellBorders in CellBackgroundPaint, it would be yet another big step way from RADness for Xojo… More so than Control.MouseX, Y removal…
Besides the obvious UI uses, not having that capability would have made creating my Mergeable Cell ListBox Subclass much more work…
I hope leaving out the CellBorder setter/getters out was an oversight that will be corrected in the next release…
-Karen
These are lost in the DesktopListbox but are available on the Listbox… Is there a replacement ?
@Geoff_Perlman
I use CellBorderBottom, CellBorderLeft, and CellBorderRight in many of Lightwright’s listboxes. Yes, I know that I can keep using these now-old-probably-deprecated-someday controls in my project, but I will be working on a new Lightwright release soon and not having this functionality moving forward just means more work for me, adding code to draw lines and rectangles.
What I’d really like to know is who decided this feature was something that could be ditched and why? Is Xojo trying to reduce the number of properties and controls it natively supports? Can someone please explain what their logic is and where we might expect downgrades in the future?
Likely making the controls less work for them to maintain… but that makes the product harder (more work) for us to use…
For multicolumn listboxes one often wants to delimit sections of the table, with different column borders and.or row borders, as well as for specific cells.
Yes one could still do it on one’s own but it then ads significantly to OUR code complexity… and I always used RB/RS/Xojo to make MY coding easier and faster.
-Karen
These all seem to be methods now. As I don’t use them, one of you folk who does will have to comment on whether there is a practical difference here between property (listbox) or method (DesktopListbox).
What are you referring to?
Where do you see CellBorder methods? I don’t see any in the language reference.
-Karen
Humph - yes, I may have spoken too soon, sorry. A couple of properties seem to have been moved but not the border ones.
Thanks for that, but why respond to that but not the bigger issue that started this thread. How are cell borders set now?
1 Like
The feeling was that if you want borders around a specific cell, there’s an API for that. If you want draw partial borders, that can be done easily enough in CellBackgroundPaint.
We consider every class member we add because more isn’t always better. The more there are, the more complicated the class becomes. That makes it harder to learn, more likely to have bugs, etc.
Having said that, if we heard from enough people that they really want specific methods, we would reconsider them.
Speaking as someone who has done more than most with the API 1 listbox, to do it right and do it generally and not just as one off usage is NOT that simple… It is a feature that I and I suspect many others use routinely…
Doing it as one-offs would have a HUGE overall impact on my development time… and reinventing the wheel is not what I want to spend my money to do!
The Listbox is a vital control and being able to just set the boarders is a big part of what made it able to do good UI without too much effort.
You keep taking away the things that made me (and I suspect many others) fall in love with RB by making it easy to use and RADish without having to compromise a lot, by just doing a little work.
I hope API 1 (both controls and code) gets supported (at least fixes for new bugs introduced or for OS changes) for 5 more years.
Harder to learn? You mean you think it is easier to learn/use the cellBackgroundPaint methods, worry about exact positions of where those should be, than just using the API 1 Listbox border methods? REALLY???
Not For us…
How would having both cause bugs? I just can’t see it.
The BackgroundPaint events are an “Advanced” feature that starting coders won’t get the hang of right away. The methods are much simpler, never mind much faster to write code using them.
I have to wonder if the motivation is more to make the framework code easier for Xojo inc to maintain, rather than making Xojo easier to use for it’s customers. If that’s the case then please just say so.
For me at least coding UI stuff typically takes far longer than anything else and removing things that make that easier will only make it more of a chore.
<s
BTW Maybe you should consider removing Keyboard equivalents or menu items for the IDE UI or contextual menus … after all having all those way to do the same thing might confuse someone sometime somewhere somehow…
</sarcasm
I don’t mean to offend with that… but I find removing features I have depended on for years disturbing, and the reasons given for it even more so.
-Karen
5 Likes
I use borders extensively in my products, with both the CellBorder methods and in the CellBackgroundPaint events, if I have very specific needs. The CellBorder methods are always desirable to try to use, as CellBackgroundPaint requires a lot more code to check rows and column limits, thick lines require an extra line of code, etc… I assume you took it out for some reason, but for established products, just one more reason to stick with old controls. Who wants to make substantial changes to the UI code on 20+ ListBoxes because the compiler changed?
3 Likes
The Documentation is still faulty.
Me.CellBorderColorAt(0, 0) = Color.Red
The examples refer to CellBorderColorAt with the spurious At at the end. CellBorderColorAt does not seem to actually exist.
CellBorderColor is described as being a Method of the DesktopListBox, but the examples seem to treat it like a property.
It is all pretty confusing. When I tried updating existing projects I got all these errors related to CellBorderBottomAt etc. of the old Listbox being converted to DesktopListbox and then being declared erroneous. The new CellBorderColor is described as a method; CellBorderBottomAt etc. were properties. The examples under CellBorderColor are faulty.
It is hard (for me) to even contemplate updating my old code when the Documentation is so unclear/incomplete.
Further complicating things, the Language Reference brought up by clicking on the Help button in the IDE is different than looking up documentation.xojo.com in terms of trying to explain CellBorderColor. The examples are erroneous in both.
I think the reference is to: PaintCellBackground of the new DesktopListbox.
1 Like
Some of this is clarified by a comment that Paul Levebre left elsewhere:
“Many years ago (10+), getter/setter methods were listed as properties in the docs. With API 2 stuff we are listing them as the methods they truly are so that people realize 1) they won’t be shown in the debugger and 2) that they can be overridden.”