chris25 wrote:In 20 years of using a million pieces of software I have never ever ever had to ask or even look up in some instructions about where to find what font I am looking at or high-lighting?
The property that governs the font used by text in LiveCode is called textFont, and can be obtained for an object or a chunk of text, e.g.:
set the textFont of btn 1 to "Helvetica"
get the textFont of selectedChunk
The textFont property in inherited, so that if the object or chunk doesn't have it explicitly set it will inherit the textFont of its owner. To account for cases where the textFont isn't set directly on the element you're querying, you can use the "effective" keyword:
get the effective textFont of word 3 of fld 1
The "effective" keyword can also be used for other inherited properties, like textSize, textHeight, backgroundColor, etc.
Please don't annoy me by asking me whether I have looked in the 'obvious' places in livecode.

Many of us ask for that information for two reasons:
1. To provide a more complete learning experience.
In those cases where we can help folks understand where learning materials are found and how they're laid out, many times this can be very liberating for users to know, as they can more readily anticipate where they might look for answers to other questions down the road, and find those answers more quickly and easily.
It's the old "teach a man to fish" thang, and it's been helpful for much of human learning for centuries, no less so when learning a programming language.
In this case, for example, using the search box in the Dictionary filtering for "font" shows 12 entries, most of which are fairly obviously not what you're looking for, and "textFont" is among them. While it would require skimming a few entries to discover the one you need, using that approach will not only help you find what you're looking for in a few seconds, but also introduce other font-related tokens which may be useful later on.
The Dictionary currently suffers from the classic problem in most API reference info (see #2 below), but it's often a good starting point for exploring the LiveCode language.
2. To improve the documentation
The LiveCode Dictionary contains most of the information one needs to use the language well, but like most API references it sometimes requires the user to be able to anticipate specific terms to find what's needed.
One way to alleviate that would be for the Dictionary to include synonyms or other additional tags in its index, so that when filtering for a term that's not literally part of the token needed, conceptually-related terms could still yield useful results.
The challenge with adding such tags to the index is that those of us in a position to do so, who have sufficient interest and experience to contribute to the development of the IDE, know the language too well to be able to anticipate the range of terms people might use when searching for a particular item. This "too much familiarity" is the classic problem which describes why programmers can't adequately test their own code and why usability studies are critical for good design, and it applies equally to the task of anticipating how new users conceptualize their search terms.
Since indexing is a keen personal interest of mine, and since much of my work involves teaching LiveCode, I frequently ask folks who are looking for information to please assist this process by describing the steps they took on their own before bringing their question to the forum.
My hope is that I'll be able to gather enough information to propose a sort of synonym lookup table, similar to ones I've implemented in embedded search engines I've written for other products in LiveCode.
But of course, to be able to do that will require a bit of crowdsourcing, some assistance from newcomers who've noted that they've had difficulty finding what they're looking for.
I hope this background helps mitigate some of the annoyance with the questions you'll see here from myself and others. We're really only trying to help.