Make the container buttons scope Private. In ContainerControl1 add a method SetButtonEnabled(assigns isEnabled as boolean)
If instead of letting code outside the container reach in and manipulate the control directly we provided an API to do this and hid the innards then we could be sure we have fewer places to fix and that no code outside the container isnt somehow changing the setup in some way that will cause other issues. You simply hunt for and change the names and off you go.īut, you may have to do this many times depending on how many times you set the enabled state of the button. Now in a small application this is manageable. Type "ContainerControl1.ContainerControl1" has no member named "PushButton1"Ĭ = false If we rename PushButton1 to “ContainerButton” and try to run again we’ll get an error saying Window1.Open, line 1 In the project we’ve built so far this isnt so bad. And one of those changes is to rename the button to something more meaningful. And perhaps you reuse this container on several other windows.Īnd then you decide to make some changes to the container. Now imagine you add a lot of other functionality to your application and there are several places where your code enables or disables this button under various conditions. In there put = falseĪnd when you run the pushbutton on the container will indeed show up as disabled. Now add an instance of this container to Window1. Lets walk through a quick and simple example that illustrates the issue.Īdd a container control to the project – it will cleverly be named ContainerControl1.Īdd a Generic Button to this container.
Why, when you create this new container, would you then make all the controls on it public so code outside the container can change it ? That seems like it would be a good way to ruin the encapsulation you’re trying to achieve.Īnd, if you do this, any changes to your nicely set up container then may require broader changes in your application if, or when, you make changes to your container. You’re already thinking about “encapsulation” which is a good thing. Suppose you are creating a new container control to encapsulate some functionality onto this new control. Observing the view hierarchy is just one really useful one. There are lots of other things you can do in Xcode once you have attached to a process to examine it. But it does tell you what Cocoa UI element an object is in case you need to use declares to manipulate it. This wont always tell you something really useful in the lower panes. You can, in this view, see what is in front of or behind something else and that can help you resolve weird drawing issues and may help reveal how other applications achieve specific affects like the translucency seen in the Finders left hand navigation panes.Īs well in this view you can right click on any view and select the “Print description of” menu item. There are scrollers on the bottom left to adjust the separation of the layers so its easier to see them. You can slick and drag in the view area and Xcode will reveal the various layers used to composite the image you see on screen. Once you do that you get what appears to be a 2-D wire frame drawing of the user interface views. Select Debug > View Debugging > Capture View Hierarchy. A small panel should appear and in here you can put the PID from Activity Monitor. Select Debug > Attach to Process by PID or Name. The number in that column is what you need. I happened to show the Memory usage but other views like CPU time also have a PID column.
I’m going to select Xojo since everyone reading this should have a copy. Start Activity Monitor so you can get the the PID of your running application. Save that project in a new folder on your desktop since we’re going to throw it away when done. It doesn’t matter what you call it just that Xcode wont work for this without an open project. If you’re having issues getting things to appear correctly this can be very handy to know whats above or below what in the entire view hierarchy that macOS uses to create what you see on screen. In Cocoa every control is a kind of “view” and your entire UI is composed of multiple views one on top of the other and composited together. Perhaps the handiest things Xcode can do is examine the view hierarchy of ANY application. Select that template and edit and you have a plist ready to add to your Xojo project. If you start Xcode and select File > New > File and scroll down there is a section that lists various kinds of files that you can edit. Xcode has an excellent editor for plists. Since you can drop a plist into Xojo to supplement or replace certain keys at some point you may need to create one. I know a lot of you don’t want to mess with Xcode BUT there are some really handy things it can help you with and you don’t have to write any Swift or Objective-C code.