Learning from across they way #13

[richmond62]

I think LC does a disservice to new users by not displaying menumode in the property inspector. It does exist, but LC has set up all the "different" buttons in the tool palette which already have their menumode set.

LC actually has only one button object and one field object. The different variations you see in the palette are just using different properties. If you want to change the menumode of a button you can still do it from the message box. The same is true for any other properties that aren't in the inspector.

emphasis is mine.

https://forums.livecode.com/viewtopic.php?t=34028

Although I do not entirely understand that as we have this:
-

Screenshot 2024-11-23 at 13.04.18.png (203.68 KiB) Viewed 692 times

-
BUT there is NOT a drop-down menu to rapidly transmogrify one type of field into another type, and I do feel one would be a great addition.

That short thread is quite a mine in some ways as it also mentions this:

The last technique refers to the "Replicate" command which does not appear in my Indy 9.5.1 edition of LiveCode.

'Replicate' was last seen in vers. 7.x under the 'Edit' menu, however, much like it sounds, it just means to make copies of whatever object your replicating. I really don't know why it was removed, I love using it for certain things

I wonder if it is possible to restore replicate in OXT?

[richmond62]

Screenshot 2024-11-24 at 20.01.59.png (216.43 KiB) Viewed 654 times

-
This is a bog-basic thing that will transmogrify the simple text field at the top of the stack into a table field.

Code: Select all

on mouseup
   if exists(fld "myField") then
      delete fld "myField"
   end if
   clone fld "f1"
   set the name of the last field to "myField"
   ---
   set the width of fld "myField" to 400
   set the height of fld "myField" to 600
   set the top of fld "myField" to 100
   set the left of fld "myField" to 200
   ---
   set the disabled of fld "myField" to false
   set the vis of fld "myField" to true
   set the sharedText of fld "myField" to false
   set the dontWrap of fld "myField" to true
   set the lockText of fld "myField" to true
   set the opaque of fld "myField" to true
   set the traversalOn of fld "myField" to true
   set the showFocusBorder of fld "myField" to true
   set the autoTab of fld "myField" to false
   set the threeD of fld "myField" to true
   set the showBorder of fld "myField" to true
   set the borderWidth of fld "myField" to 2
   set the hScrollbar of fld "myField" to false
   set the vScrollbar of fld "myField" to true
   -- scrollbarWidth
   set the autoHilite of fld "myField" to true
   set the listBehavior of fld "myField" to false
   set the multipleHilites of fld "myField" to false
   set the nonContiguousHilites of fld "myField" to false
   set the toggleHilites of fld "myField" to false
   set the firstIndent of fld "myField" to 0
   set the dontSearch of fld "myField" to false
   -- layerMode
   -- behavior
   set the basicTableObject of fld "myField" to true
   set the cellEdit of fld "myField" to true
   -- maxColumnCount
   set the cellFormat of fld "myField" to false
   set the showLines of fld "myField" to false
   set the hGrid of fld "myField" to true
   set the vGrid of fld "myField" to true
   set the tabStops of fld "myField" to 75
   -- set the foregroundColor of fld "myField" to "Text fill"
   -- set the foregroundPattern of fld "myField" to "Text fill"
   -- backgroundColor
   -- backgroundPattern
   -- hiliteColor
   -- hilitePattern
   -- borderColor
   -- borderPattern
   -- topColor
   -- topPattern
   -- bottomColor
   -- bottomPattern
   -- shadowColor
   -- shadowPattern
   -- focusColor
   -- focusPattern
   -- customProperties
   -- blendLevel
   -- ink
   -- textFont
   -- textSize
   -- textStyle
   set the textAlign of fld "myField" to "left"
   set the fixedLineHeight of fld "myField" to true
   -- textHeight
   set the margins of fld "myField" to 8
   set the lockLoc of fld "myField" to false
   -- width::revIDESetRectProperty
   -- height::revIDESetRectProperty
   -- dropShadow
   -- innerShadow
   -- outerGlow
   -- innerGlow
   -- colorOverlay
end mouseup

[richmond62]

Screenshot 2024-11-24 at 20.17.52.png (175.31 KiB) Viewed 651 times

-
The scripts in these buttons could be popped into a drop-down button/menu, and eventually put in the Properties palettes for fields.

[richmond62]

Here is "The Road to Hell":

Contents/Tools/Toolset/resources/supporting_files/property-definitions.

https://youtu.be/gUUdQfnshJ4

[tperry2x]

I'm sure it would be possible to restore the "Replicate" option - I'll look into it.
edit: found it in LCC 7, and it works in OXT Lite. I just have to put it back in the menu... shouldn't be too hard.

replicate.png (19.52 KiB) Viewed 639 times

Edit 2:
This is now done, back in OXT Lite, and working:

added.png (52.11 KiB) Viewed 636 times

[richmond62]

Thanks: that is great.

1.10 presumably?

[richmond62]

AND, as I have demonstrated with that stack, it would be possible, as well as providing buttons and/or menuItems to all the field types offered on the Tools palette, to offer all sorts of "kinky variants".

Of course if one were a complete nutter (who? me?) one could provide a stack with, say, 25 + drop-down menus
(one for each property a field can have) so end-users could go completely bonkers making all sorts of funny fields . . .

Lying in bed with a high temperature really made me go seriously 'aff': and look at the result.

One of the things that has become extremely clear to me "over this" is how all the idle words bandied about somewhere else about empowering
users were nothing but twaddle.

[tperry2x]

Thanks: that is great.
1.10 presumably?

I've actually managed to do it as two updates. Regrettably there are two, because the updates stack needs updating
Then it needs to reload, and grab the other fixes. Should take you to build 202411250915 if all goes well.

[tperry2x]

AND, as I have demonstrated with that stack, it would be possible, as well as providing buttons and/or menuItems to all the field types offered on the Tools palette, to offer all sorts of "kinky variants".

Of course if one were a complete nutter (who? me?) one could provide a stack with, say, 25 + drop-down menus
(one for each property a field can have) so end-users could go completely bonkers making all sorts of funny fields . . .

Lying in bed with a high temperature really made me go seriously 'aff': and look at the result.

I'm not entirely sure I follow this. Sorry if I'm being slow on the uptake (as normal).
What is the advantage or difference between that "fielder" stack and just having a stack of assorted fields that a user can simply copy and paste?

Editing the inspector to do anything is a complete can-o'-worms. One that I don't want to open.
I'm making an inspector to replace it, but every time I get back to it, I get overwhelmed by the fact that it's such a task. I can see why nobody has written a replacement so far.

Anyway, hope you feel better soon. T'is the season for it.

[richmond62]

What is the advantage or difference between that "fielder" stack and just having a stack of assorted fields that a user can simply copy and paste?

Well, if there is any advantage at all:

1. The stack I have created allows one to see all the twiddly-bits that differentiate the types of field currently on offer.

2. If I go bananas and make a 'thousand flowers' type of stack, all and everyone will be able to dream up their own types of fields which
may suit their needs better than the few supplied.

Certainly it does NOT do anyone any favours to give the impression that each field type is some type of primitive that is independent from other field types.

[tperry2x]

f I go bananas and make a 'thousand flowers' type of stack, all and everyone will be able to dream up their own types of fields which may suit their needs better than the few supplied.

Ah, I see. Makes sense.
How about a kind of "Field-o-matic" stack which has "Create a new field:" text, then underneath - a series of dropdown menus and selection boxes where the user can customise as they need. They then click a "create field" button and it places it into their stack.

I would mock something up, but away from the computer at the moment.

[richmond62]

I've actually managed to do it as two updates. Regrettably there are two, because the updates stack needs updating
Then it needs to reload, and grab the other fixes. Should take you to build 202411250915 if all goes well.

Indeed: 3 + 7
-

SShot 2024-11-25 at 13.44.38.jpg (128.17 KiB) Viewed 558 times

[richmond62]

How about a kind of "Field-o-matic" stack which has "Create a new field:" text, then underneath - a series of dropdown menus and selection boxes where the user can customise as they need. They then click a "create field" button and it places it into their stack.

Far better would be to have a field present on the stack, and as each property is set the field adopts that property:

This will allow the user to see what is happening to their field (your way they will be fumbling around in the dark).

If you look back at my stack you will see the first bit in each button clones a bog-basic field, renames it, resizes it, and repositions it: BEFORE any props are changed.

[tperry2x]

Okay, I'll leave it to you to come up with what you think works best.
I was originally thinking something like the Object Library, but for your fields:

like-this.png (66.83 KiB) Viewed 511 times

[richmond62]

I'll go for the nutty-fruitcake variety . . .

This COULD involve as many as 69 drop-down menus.

[OpenXTalkPaul]

After a quick scanning of this thread I have the following comments:

I was wondering where that replicate stack went. I believe I've mentioned I the past I and no one seemed to cared at the time. I pulled in that stack from the v7 IDE folders, but I never actually used it before. Seems like it could be rather handy (like a step & repeat functionality of page layout apps).
Additionally there is a revSnippetsEditor stack (which I think had something to do with AutocComplete), plus there's some old demo stacks and a few dated help stacks (like an old key-combo list) in the documentation folder that were no longer linked to anywhere in the IDE (before it got dropped into our laps).

Adding a menu choice for changing a button style to menumode should no problem at all. I did that same sort of modification to add 'oval' button style back in (although oval button style is a little flakey so I'm not adding it to the tools palette), it's just a matter of adding it in the right places in those Property files as Richmond pointed to.

You don't need to do that for changing a text field to tab field as that can be changed from a 'table" checkbox in one of the other Property Inspector tabs (the one where the tab-stops go).

I've made some fixes to my revImages / revObjects stack like making it so creating new libraries actually works, plus tweaks like drag-drop to place. Also I have included revOXTObjectLibrary which you're welcome to use for whatever, that is a secondary library for that window which has a bunch of controls I'd saved for my own use (which may or may not be useful to a general audience) and figured I'd share it. For one thing it might not be clear that you CAN make your own Object libraries (which is an extremely useful thing IMO, so it's weird to me that most people don't seem to even use the thing).

Tricky, that screen shot is Linux with a macOS 'like' Mohave dark theme, judging by the tabs.
That's pretty much the same as my MX Linux install looks now too

[richmond62]

I wonder why, in the OXT scriptEditor a few properties of fields are NOT highlighted:
-

Screenshot 2024-11-26 at 13.09.41.png (31.35 KiB) Viewed 364 times

-
HighLighted property.
-

Screenshot 2024-11-26 at 13.09.15.png (34.08 KiB) Viewed 364 times

-
Whoops.

"Shopping List":

basicTableObject
cellMode
maxColumnCount
cellFormat


Aha! These properties DO NOT have entries in the Dictionary.

[tperry2x]

I think the script editor isn't recognising it, because...

Code: Select all

set the basictableobject of fld [x] to "true" 

...is only adding a custom property to the field.

Not changing anything to do with the basictableobject setting.

I know the inspector is labelled up as "basictableobject" when you hover over the button, but I don't think this is what's actually being set. (I don't know what it's actually setting to achieve this toggle), but doesn't seem to be "basictableobject".

ChatGPT to the rescue:

When you enable the basicTableObject option in the Property Inspector, it doesn’t directly set a special engine-level property. Instead, it performs a sequence of operations to configure the field object. These changes include setting custom properties and applying specific visual and behavioral attributes to the field.

Code: Select all

set the cellformat of fld [x] to "true" 

Seems to be another one that's potentially labelled as one thing, but is internally something else altogether (which makes creating a replacement inspector total guesswork from my point of view).

Haha, you beat me to it. [posted at the same time]
Yes - these don't seem to have any effect other than setting custom properties. They don't seem to change / toggle anything in the inspector.

[richmond62]

Screenshot 2024-11-26 at 13.37.48.jpg (198.48 KiB) Viewed 352 times

-
Well, here's a toy to play around with.

[tperry2x]

Please see my post above (we posted at the same time).
This is why setting cellEdit does nothing (other than set a custom property). Just tried your stack and that cellEdit has no effect.

Because cellEdit isn't actually labelled up correctly in the inspector. (Not sure what is actually getting applied here when you click that button in the inspector), but it does not seem to be 'cellEdit'. It's a mystery!
The same is true for all the other unrecognised properties that the script editor doesn't know - all they do is set custom properties.

example:

Screenshot at 2024-11-26 11-48-50.png (20.04 KiB) Viewed 344 times

Screenshot at 2024-11-26 11-49-15.png (22.81 KiB) Viewed 344 times

still off:

Screenshot at 2024-11-26 11-51-27.png (36.21 KiB) Viewed 344 times