What I'm adding, and what I'm planning next...

[mwieder]

Replying to myself... I found the section of code that overwrites the unique new control name.
Here's the corrected revIDECreateObject handler in the revIDELibrary stack (fix for LC bugzilla #21631)

Code: Select all

on revIDECreateObject pObjectTypeID, pTarget, pLoc
   if not __objectTypeIsControl(pObjectTypeID) then
      return __revIDEError("Object must be a control")
   end if
   
   if not exists(pTarget) then return __revIDEError("Cannot create object. Target does not exist: " && pTarget)
   if not pObjectTypeID begins with "com.livecode" then return __revIDEError("No such object type ID: " && pTarget)
   
   if sClassicObjectProperties is empty then __objectPropertiesRead
   # Set the default stack to the target we're creating the object on
   set the defaultstack to revIDEStackOfObject(pTarget)
   
   if pLoc is empty then
      put the loc of this card of the defaultStack into pLoc
   end if
   
   # Create the object
   lock screen
   lock messages
   
   local tPropInfoA, tObjPropsA
   # Get the engine control type
   if pObjectTypeID begins with "com.livecode.interface.classic" then
      local tCreatedControlID
      # Create data grid
      if pObjectTypeID begins with "com.livecode.interface.classic.DataGrid" then
         -- data grid library expects a rect rather than a loc
         local tCreateRect
         put round(the cTabButtonWidth of stack "revPreferences" / 2), round(the cTabButtonHeight of stack "revPreferences" / 2) into tCreateRect
         put item 1 of tCreateRect + the cTabButtonWidth of stack "revPreferences" into item 3 of tCreateRect
         put item 2 of tCreateRect + the cTabButtonHeight of stack "revPreferences" into item 4 of tCreateRect
         
         local lDataGrid
         put true into lDataGrid -- select data grid at end not single control
         
         unlock messages
         # tObjectId is passed by reference and will have the data grid group id placed into it
         addDataGridToStack the short name of this stack, tCreateRect, empty, empty, tCreatedControlID
         local tCount
         put 0 into tCount
         repeat with i = 1 to the number of groups
            if the dgProps["control type"] of group i is "Data Grid" then
               add 1 to tCount
            end if
         end repeat
         set the name of tCreatedControlID to (the short name of tCreatedControlID && tCount)
         lock messages
      else
         local tObjectType
         put sClassicObjectProperties[pObjectTypeID]["type"] into tObjectType
         
         if tObjectType is empty then return __revIDEError("Invalid classic control type ID: " && pTarget)
         
         # A classic control
         do "create" && tObjectType
         put the long ID of the last control into tCreatedControlID
      end if
      
      put sClassicObjectProperties[pObjectTypeID]["properties"] into tObjPropsA
   else
      # Not a classic control
      try
         if pObjectTypeID is "com.livecode.widget.native.map" and the platform is "MacOS" and (revIDEPlatformVersion() begins with "10.9" or revIDEPlatformVersion() begins with "10.10") then
            local tMessage
            put "The Mac MapKit API is supported from OS X 10.9 onwards, but Apple restricts use of the API on 10.9 and 10.10 to apps which are distributed from the Mac AppStore with an appropriate entitlement. " & \
                  "Due to this, general use of the Map widget only supports OS X 10.11 onwards. " & CR & CR & \  
                  "However, you can still create a standalone with the Map widget on OSX 10.9 or 10.10 (of course you will see an empty grid rather than the actual map), " & \
                  " BUT this standalone will run as expected on OSX 10.11 and above." into tMessage
            
            answer warning revIDELocalise(tMessage) with "Cancel" and "Continue"
            if it is "Cancel" then exit revIDECreateObject
         end if
         
         create widget as pObjectTypeID
         put the long id of the last control into tCreatedControlID
         
         put revIDEExtensionProperties(pObjectTypeID, false) into tObjPropsA
         union tObjPropsA with sClassicObjectProperties["com.livecode.interface.classic.widget"]["properties"]
         
         local tSize
         put revIDEExtensionProperty(pObjectTypeID, "preferredsize") into tSize
         if tSize is not empty then
            put item 1 of tSize into tObjPropsA["width"]["default"]
            put item 2 of tSize into tObjPropsA["height"]["default"]
         end if
      catch tError
         return false
      end try
   end if
   
   __setPropertiesToDefaults tCreatedControlID, tObjPropsA
   
   ## Set the size of the object to the size set in the Preferences
   __setSizeToPreference tCreatedControlID, pObjectTypeID
   
# start of added section
   local tObjectNumber, tObjectName
   set the itemDelimiter to "."
   put 1 into tObjectNumber
   put item -1 of tObjectType & tObjectNumber into tObjectName
   repeat while there is a control tObjectName
      add 1 to tObjectNumber
      put item -1 of tObjectType & tObjectNumber into tObjectName
   end repeat
   set the name of the last control to tObjectName
#end of added section
   
   set the loc of tCreatedControlID to pLoc
   
   unlock messages
   unlock screen
   
   ## Prevent passing of ideNewControl message for objects created on IDE stacks
   if revIDEObjectIsOnIDEStack(tCreatedControlID) is false then
      // AL-2015-04-08: [[ Bug 14822 ]] Ensure 'edited' status of stack is set
      revIDESetEdited the short name of this stack
      ideMessageSend "ideNewControl", tCreatedControlID
   end if
   
   return tCreatedControlID
end revIDECreateObject

[tperry2x]

That's brilliant. Thanks Mark.
I've incorporated this into OXT Lite and it'll be in an update soon.
Many thanks - now all new objects created have unique names (rather than just being called 'button' for example).
I'll credit you in the release notes too

Changed part:

Code: Select all

on revIDECreateObject

Code: Select all

 # start of added section
   local tObjectNumber, tObjectName
   set the itemDelimiter to "."
   put 1 into tObjectNumber
   put item -1 of tObjectType & " " & tObjectNumber into tObjectName
   repeat while there is a control tObjectName
      add 1 to tObjectNumber
      put item -1 of tObjectType & " " & tObjectNumber into tObjectName
   end repeat
   set the name of the last control to tObjectName
   #end of added section

You'll note, I did tweak your code very slightly - just to put a space before the number, so "button1" "button2" becomes "button 1" "button 2" for example.

[micmac]

Could the word button be a prefs?

Mic

[richmond62]

That sounds a good idea.

Mind you I expect everyone renames their buttons once they have made them.

[mwieder]

The object type is passed as a parameter to the handler, but it has to be one of the defined types: either a "classic" control or one of the available widgets. So you can't create a new dinosaur 1, for example, unless you have a dinosaur widget.

Although we could have an optional trailing parameter to supply a new object type name for the new control.
Is there a use case for this?

[micmac]

button 1 = button number 1 (btn 1)

"button 1" = a name

Can be confused

Mic

[mwieder]

Right. I understand that. It's just that renaming at this stage in the IDElibrary stack in a handler that's only called from the tools stack when you drag a control onto a target stack doesn't sound like the best place to have that action.

[tperry2x]

Yes, I could make it a preference.
What about this?

Code: Select all

   # start of added section
   local tObjectNumber, tObjectName
   set the itemDelimiter to "."
   put 1 into tObjectNumber
   put item -1 of tObjectType & " '" & tObjectNumber & "'" into tObjectName
   repeat while there is a control tObjectName
      add 1 to tObjectNumber
      put item -1 of tObjectType & " '" & tObjectNumber & "'" into tObjectName
   end repeat
   set the name of the last control to tObjectName
   #end of added section

So you'd get Button '1', Button '2' etc?

Or, alternatively:

Code: Select all

 # start of added section
   put char (the number of chars in the seconds -4) to (the number of chars in the seconds) of the seconds into tLastFourChars
   put "ABCDEFGHI" into tAlp9
   put 0 into xCount
   repeat 4
      add 1 to xCount
      put char xCount of tLastFourChars into tNumSec
      put char tNumSec of tAlp9 into tChosenAlpha
      put tChosenAlpha into char xCount of tLastFourChars
   end repeat
   put random(4) into tRandChar
   put random(9) into char tRandChar of tLastFourChars
   set the name of tCreatedControlID to (tObjectType & " " & tLastFourChars)
   #end of added section
   

Gives you:

dont-give-me-names.png (8.21 KiB) Viewed 3475 times

[richmond62]

Dunno what the advantage of all those single quotes is.

[mwieder]

Yeah, given that everyone renames controls after they've been created anyway.

[tperry2x]

Dunno what the advantage of all those single quotes is.

Just so it won't be confused with an ID number, as per comment above.

[mwieder]

Leaving out that space accomplishes the same thing, no?

[tperry2x]

Leaving out that space accomplishes the same thing, no?

Well, I kind of thought so - until I spotted the button name on Windows. Because the windows system font is so innacurate, it's sometimes hard to tell if you have a space or not, so I was trying to at least make it uniform.
I guess another way would be to have it label as button A, button B and so on...

[FourthWorld]

Why not just let an unnamed control remain unnamed until the user chooses to name it?

[micmac]

It can be an advantage to quickly have a lot of button (with a unique name) that have sequential numbers

Then they all can be addressed with a "repeat with i = 1 to tNumber"

Mic

[FourthWorld]

It can be an advantage to quickly have a lot of button (with a unique name) that have sequential numbers

Then they all can be addressed with a "repeat with i = 1 to tNumber"

I probably missed a key post earlier. Are we talking about a tool for the user to choose to apply to a selection of objects as needed, or a default IDE behavior?

The former would be useful.

If the latter, I can't remember the last time the IDE chose to name an object in a way that correctly guessed what I wanted.

But I do recall when the IDE insists on adding names in the inspector to objects that have no name, and how it requires a small extra effort to select it when I want to actually name it. That's pretty much every day I'm LC. And that's among the reasons I rarely use their tools.

[mwieder]

Ah. So don't even bother naming the control on creation since it'll have to be renamed anyway.
That makes some sense.

[FourthWorld]

Ah. So don't even bother naming the control on creation since it'll have to be renamed anyway.
That makes some sense.

IIRC leaving unnamed controls unnamed until the user chooses to name them was how HC, SC, OMO, Gain, Toolbook, MetaCard, and early Revolution worked.

[mwieder]

Just looked this up. HyperCard named new buttons "New Button".
Revolution always named controls by their type: "Button", "Field", etc.
Both annoying.

Although apparently you could double-click the button on HyperCard's Tools menu to bring up the inspector and set a name there before object creation.

[richmond62]

Presumably if you 'just' want to stop the IDE always calling new button 'Button' you can edit things in the TAB delimited text file /Contents/Tools?Toolset/resources/supporting_files/property_definitions/com.livecode.interface.classic.Button.tsv, changing 'Button' to 'FishFace' or whatever you want?
-

Screenshot 2024-07-18 at 17.35.23.png (357.01 KiB) Viewed 3455 times

-
A bloody stupid one word edit proves the point:
-

Screenshot 2024-07-18 at 17.43.54.png (65.55 KiB) Viewed 3455 times

-
What is interesting is that I wonder if I mod one of those TAB delimited files in LibreOffice and rename it, if that should not be enough to produce a new object?????