As I’m sure many of you know, sometimes when you use the simple settings (Properties tab of the Customization Tools Dialog) to set Visible = False on a native UI control, it doesn’t always work. It looks like it works when you’re in the customization, but it pops back up when using the program. Usually I see something will stay hidden on a “blank” screen (say, for example the Quote -> Lines tab when the Quote has no lines), and it will re-appear when there is data on the screen.
Others have said this is because the control properties are being overridden by the data field properties to which the control is Epi-bound. Sounds reasonable, but I can’t say for sure that’s what’s going on.
To those who have dealt with this - what strategies have you found most effective? Here’s some options I’ve tried or heard about:
Make the control size 0,0
Move the control location off the screen / group box
On a related note – The ReadOnly property of a UI control is not reliable either. If I want that data field ReadOnly everywhere, I can use Extended Property Maintenance and that works. Or I can set the extended property of the data field in custom code. I have also used the Enabled property on the control and that worked at least one time that I can remember (when ReadOnly on the control did not work). My question - what exactly does Enabled on a control do? Can’t find much insight on this and am curious.
Bit of a tangent – Any thoughts to share on when to hide an unused field and when to let it be? Sometimes I want to just hide everything that we don’t use to make it simpler for users, but I also like giving people the ability to say “hey, what does this do?” and mull over what they might use that feature for in the future. Many times I’ll even completely forget about functionality because it’s been hidden away on the form for so long.
If I could do it all over again, I’d hide nothing and only put custom controls in their own tab. Hiding native controls is a recipe for losing functionality and causing headaches with upgrades. Often times users want things hidden because it doesn’t look like their old system did and therefore hiding it will make the new scary system go away. But over time, this approach is harder and harder to maintain.
So yes the things you said will work, I just wanted to share my experience with this topic as I went down that path early on and I’m still paying the maintenance and functionality price for it today.
In my opinion whether or not to hide a control depends on how often the screen is used. If it’s a rarely used screen like part class, leave all the standard controls alone and put any custom controls on a new tab. If it’s a screen like order entry that is used constantly I think it should be streamlined for the best user experience. I normally hide controls by moving them to the left off screen by putting a -1 or -10 in front of their current position. Then they are always off the screen and I can easily put them back exactly where they were if I want to. I also like to have a base version of the screen available so it easy to see the standard functionality.
I don’t like to hide the controls, but if required, I typically make them off the screen by adding 1000 to the current location. Then it is easy to replace when you find out that you need the field afterall (remove the 1000).
I agree with Tim. Come up with a number that you will remember and use that in all of your customizations. Having just implemented, it was easy to undo some of the changes I made based on this method.
In addition to what other users have mentioned about changing the position/size of the control(s)
I also like to go thru the “TabStop” property on those “hidden” controls and set it to false.
So users can’t inadvertently tab into any of those field(s).
Occasionally I’ve also hidden controls by setting the “Visible” property to false.
But… for some reason I remember this as being “hit & miss”.
The visible property will be altered by row change logic, where following a change everything on that view gets set to a default state and then row rules come along and subsequently hide, disable or whatever. So you may set visible=false on the control but chances are row change logic will subsequently fire and change it again. So, one thing could be to change the default state - do that by setting extended property for visible to false. However I have to admit I do like others here have mentioned and add a negative number to the X-offset by putting -1 or -100 in front of it.