There are also bigger tools that give a lot more detail than just layout elements: BaseElements and Inspector Pro.
Hot Dawg! Thank You for these references. I generally don't like to rely on freeware but I am still recovering from the price tag for the FMP-ADV license and fmXRaySpec is working very well; I love the speed of the object data transfer process via the clipboard - innovative. Thank You.
It would be nice in future versions of FMP to either include the object type in the Info Panel or somewhere in the developer bar along with the object name and window position. Those basic object attributes should be easily seen when an object is selected - IMO. I suppose I should go look for a wish-list board or other suggestion box. Thanks again.
is there any way other than to open it (dbl click) to quickly view what type it is?
Could you give an example of this, perhaps a screenshot?
What are some of the objects that you can't tell right off the bat what type they are?
(not trying to say that you *should* know what they are right off the bat, just wondering if there is something that I a missing that I could second in a feature request).
I am looking at the Desktop/Invoice Details Layout as an example from the Invoices Template. As I single click on Layout objects they all update details in Info Panel but nothing is displayed about the type of object selected. I select around on what I suspect are labels, fields, buttons, portals, sliders, shapes, etc. but none of them are identified - even the button used to create them doesn't turn dark. Many overlap and/or are hidden for formatting, etc. I single click the Add Line Item which visually looks like a button but nothing confirms such. I dbl click and it opens a window and a Popover Button Setup - I now know that it is indeed a button and what kind. The portal looks like it contains another portal and it does which I confirm with another drill down dbl click, but I have to get lucky and click between the embedded portal and the top line fields to finally display a highlight - no clue what it is, until I dbl-click to discover it be a slider. Without the dbl-click there is no way to know. it could be a shape, or a box, or tab control hidden behind a panel, etc. There is so much clicking that needs to be done to uncover overlapping objects that it is helpful to know what you've selected with each click.
As I migrate around the layout selecting objects, most don't have names and to uncover what I have selected can't be understood from the Info panel unless the object is linked to a field and I have moved to the Data tab to see this. Perhaps this is compounded by the fact that I didn't create this layout so I don't know intuitively what's where. Bottom line, It just feels more like hide and seek than it should which is why a list of objects would be so helpful. But selecting an object should, IMHO, display everything it can on a single panel to identify what it is: type, position, name, and linked data. Rather goofy to have to drill into the object to understand even for sure what kind of object it is and the same time risk nudging or changing it ;-)
The developer bar at the top displays the layout name, table, theme, and formatting shows type, colors, fills, etc for a selected object on the layout - just nothing that tells us what the type of object it is.
Take a look at the screen shot below - can you tell right off the bat that the Portal in the opened Portal contains a Slider?
Below I have dbl clicked in order to find that the selection is a Slider lurking beneath the portal.
Good stuff and thanks for posting it. It's always good to have a fresh perspective.
One quick note about what sounds like an expectation:
As I migrate around the layout selecting objects, most don't have names
Don't expect objects to be named. Typically they only get a name if they are later going to be targeted by a "Go To Object" script step. So most FM developers are not in the habit of naming each object on a layout. And trying to do so will probably end in a maintenance nightmare.
The portal looks like it contains another portal
Portals can not contain other portals. That's a limitation. So if you seem to see that it does then you are not seeing what you should. Probably reinforces your original point
Yes, it's been clear that objects are rarely named unless referenced, all the more reason to see what type they are when the name and data links are empty.
I misspoke - new to FMP - I should have said portal within the popover - not portal within the portal ;-) but nevertheless, I hope my original post is clear now.
A lot of it comes down to naming and development standards. If objects are hidden / stacked / ... whatever it should be noted by comments on the layout, usually in the non-visible area.
The FM template files don't really adhere to any good naming or dev standard...
You ask good questions.
I will add to the very good pointers that Wim has given you.
1. In understanding Layout Objects, you might find this useful:
2. In finding buttons (of which there are more than one type) [from layout mode] Menu > View > Show > Buttons is useful
3. You can put "dev note text" on a layout and use conditional formatting [Get ( WindowMode ) = 0, etc.] to have the text blend into the background when in the browse mode. Get(WindowMode) for a more complete implementation.
designdb Nice speed increase in the latest fmXraySpecs!
Glad to be of service. I got some good feedback from a user with simply monstrous layouts. Chasing down performance issues measured at 2 or 3 seconds can be complicated. When someone's refresh takes 5 minutes, it's actually much easier to find the culprit :-)
Thanks for the flow chart Tony. I have a copy on the wall now. I am already loving fmXraySpecs.
Here again is the same struggle (huge time loss) - I see the following in a script - "Go to Object [Object Name: 4]"- is this supposed to be the 4th Object? How do I determine what the 4th Object is? I am not able to find any Object Name "4" even in fmXRAY.