Having an issue with the padlock from locked controls showing through 'layered" controls such as the tab control and the page control. An example of my issue can be reproduced by simply dragging a tab control on a window within the IDE. Populate a couple of tab pages with a few controls such as the label, button, listbox, etc. Lock the controls then cycle through the tab pages- you’ll see the little padlock from ALL the controls regardless of what tab page you are on. The controls themselves aren’t visible but the pad lock is.
On a multilayed tab control with 3,4,5, tab pages- this becomes unworkable. RB 2012R21 and below NEVER did this. Yes- I realize I can unlock my controls but then what’s the point of being able to lock their position? Right now- 2013 r33 not usable.
BTW- Using xojo 2013 R3.3
Thanks for the reply… How did this get by beta testing??? It’s a basic / fundamental practice to lock controls on a form. Especially if you are placing controls in a container that’s in another container thats in even another container; i.e. Page Panels, each with a TabControl, each tab control having multiple tabs, each tab having… you know, those things you can’t lock anymore… controls. Whatever…
XOJO / RealBasic still hasn’t grown up. Took over 10 years to get Cocoa and it half works. The project navigator doesn’t list controls in a hierarchy format based on it’s relationship with it’s parents. Many more issues. It’s too bad. There’s some nice stuff in here too. So much potential. Been using RealBasic since v3.x, tolerated “known issues” too long. I’m done. Changing the name because they are afraid of the word BASIC… ridiculous. Visual Basic for years, the most popular programming language for the Windows world. Mac users like myself had RealBasic- but it just never kept pace since OSX. Changing the name isn’t going to fix the “known issues” - good coding and focus will.
The more things change, the more they stay the same.
Deep breath. There are over 30K cases in Feedback. A fact of life with software as complicated as an IDE is that it will always have plenty of issues, be they design issues, implementation bugs, etc. The alternative is that such software never ships. With an IDE, some problems are far more tolerable than others. This one is cosmetic in the design area. It is not pretty, but it’s also not nearly as important in the scheme of things as a crash in the framework.
Here’s what I would urge you to do if you want to help improve things like this:
- File or join a feedback report on the issue. If you file a report, do your best to be helpful to the engineers who have to verify and fix the problem. Variations of “you people suck” isn’t particularly helpful and won’t get you anywhere.
- Get in the beta program. Lots of beta bugs are filed. Sometimes, if one particularly gnaws at your hide, you can politely draw attention to it and get it more attention during that process.
- Xojo will have bugs now and 10 years in the future. At the same time, with all the bugs in it, it can help you make great products at much lower lifecycle cost than other environments. Be a cheerleader for improvement rather than an “I could do this better” critic. Learn how they use the Feedback system to prioritize things (and not how you think they should use it). It will help your outlook on things, put you in a better position to get things you really want fixed, and actually do more to improve things.
Now, have you searched Feedback for a report on this? When you find one, could you share a link here?
Brad- thanks for your input. What you say certainly is valid… if this was more of an obscure type bug. Yes- I agree, bugs are par for the course with software development. My software has bugs in it… but the difference, they don’t surface using common general functions of my software. This ‘bleeding padlock’ bug should have never made it out of Alpha. Think about it- you start a new project, place a container on a form, populate it with controls and once you have them where you want them- you lock them so you don’t unintentionally move them during development. It’s the very basic of beginning a project. I’m quite certain I’m not the only one that does this. Yet- somehow, this “got by” the alpha then beta process ???
To be honest- yes this ‘bug’ irritated me more than normal because to me- it’s not just a bug, it’s incompetence. Add that to the fact that this isn’t release 1 of XOJO2013- it’s release 3.3- and this “known issue”— is still an issue.
Regards and thanks again for your input.
Rinse and repeat thousands of times, as each Xojo customer probably has a favorite bug that wouldn’t have made it out of alpha in their shop. Now, you want it fixed. There is a process for that. It starts with a Feedback report. Were you able to find the report for this problem? Next, put yourself in a Xojo employee’s shoes. If someone comes at you with “this never should have made it out of alpha” while others are coming at you with, “hey, here’s a problem, what can I do to help you fix it?”, which one gets to the front of your line?
There are a bunch of these. Being constructive is how you get your favorite ones fixed faster.
P.S. Don’t blame the alpha and beta testers. We file the bugs that are most important to us. We have a limited time to do so, because Xojo has a rapid release model that usually ensures timely incremental releases. If you think we do a crappy job volunteer testing, you need to volunteer too :-).
P.P.S. it’s not just a bug, it’s incompetence <-- Don’t do that.
I wonder how many people actually lock controls. I never do. I realize that this must be a glaring error to you, but the rest of us may never notice it.
Depends on how many controls you manage. For an average interface, I usually do not bother. But recently I had to work with dozens of TextFields, and was happy to lock them before one of them started slipping
I lock EVERY control. As I use a Wacom tablet and not a mouse I’ve often accidentally moved controls. The locking prevents that. The brain isn’t what it was but I seem to remember that the bug report was mine (can’t check on this machine).