I have just upgraded to RR 2.9. I now find that in stacks I created in 2.2 I cannot edit the Contents property of any field using the Property Inspector! As soon as I click on the Contents text it greys out and becomes disabled. If I create a new stack I have no problem. Sounds like some some stack property that has been added since 2.2 has been set to a bad value --- but everything appears OK in the Property Inspector (stack is modifiable for example); I can put text into the field using the msg box.
What I am I missing?
Cannot edit field contents in Inspector
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Maybe there's some hickup in custom properties the ide puts into stacks. You can use altCleanStack (from gadgetplugins.com) to remove them (script colourisation will be removed). But as you said that the problem is with every single stack, I doubt that.
Ideally you can take a simple stack where this happens, and attach it to a relevant bug report.
Personally I have stopped to use the IDE in 2.9. This wasn't a decision I made, but I just stopped starting it, as I still had 2.8.1 in the dock. Thinking about why, I find it just has too many semi-unreproducible gui glitches, that prohibited me from having fun while coding.
Ideally you can take a simple stack where this happens, and attach it to a relevant bug report.
Personally I have stopped to use the IDE in 2.9. This wasn't a decision I made, but I just stopped starting it, as I still had 2.8.1 in the dock. Thinking about why, I find it just has too many semi-unreproducible gui glitches, that prohibited me from having fun while coding.
Various teststacks and stuff:
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
tried altCleanStack, doesn't help. And the bug is not easily reproducible, tried making a simple stack in 2.2 and opening in 2.9, the bug was not present. Your suggestion of using RR 2.8 sounds like a good one --- but how do I get it? Only 2.9 is available from the Downloads (and would my 2.9 key work on 2.8 anyway?)
fix for labels that won't let content change in inspector
Ah-hah! I was having the same problem from time to time in rev 2.9 and now rev enterprise 3.0, and I've just found a fix/workaround.
For me, the "poisoned" stack (in which labels cannot have their contents edited in inspector) had the HCAddressing property true. When I "set the HCAddressing of this stack to false" in the message box, the labels IMMEDIATELY allow their contents to be edited in inspector! (And this fix survives saving and quitting.)
Apparently the inspector is unhappy with HCAddressing, when it comes to editing contents of labels?
I had tried some tests before finding this solution:
Opened old hypercard stack in rev enterprise 3.0 and couldn't use inspector to change contents of any label fields, even new ones. Saved the (now rev format) stack. Re-opened... same problem. Made new stack: labels in the new stack have editable contents in the same inspector that blocks out content when I switch back to my troubled stack. Tried copying the newly created (editable) label from new stack to old troubled stack: formerly changeable contents are now unchangeable. Copy the label back to the newest editable stack and the label regains its ability to change contents in inspector. Made a substack of the troubled stack and find that labels in the substack allow contents to change, unless I copy the labels to the troubled stack. The troubled stack has no custom properties that I can see in the inspector, nor anything listed in inspector's master properties field. Application browser shows no groups. So the stack is poisoned somehow but I don't know where. Copying its labels onto another card does not let them change contents, but copying labels onto a new substack allows the labels to change contents.
For me, the "poisoned" stack (in which labels cannot have their contents edited in inspector) had the HCAddressing property true. When I "set the HCAddressing of this stack to false" in the message box, the labels IMMEDIATELY allow their contents to be edited in inspector! (And this fix survives saving and quitting.)
Apparently the inspector is unhappy with HCAddressing, when it comes to editing contents of labels?
I had tried some tests before finding this solution:
Opened old hypercard stack in rev enterprise 3.0 and couldn't use inspector to change contents of any label fields, even new ones. Saved the (now rev format) stack. Re-opened... same problem. Made new stack: labels in the new stack have editable contents in the same inspector that blocks out content when I switch back to my troubled stack. Tried copying the newly created (editable) label from new stack to old troubled stack: formerly changeable contents are now unchangeable. Copy the label back to the newest editable stack and the label regains its ability to change contents in inspector. Made a substack of the troubled stack and find that labels in the substack allow contents to change, unless I copy the labels to the troubled stack. The troubled stack has no custom properties that I can see in the inspector, nor anything listed in inspector's master properties field. Application browser shows no groups. So the stack is poisoned somehow but I don't know where. Copying its labels onto another card does not let them change contents, but copying labels onto a new substack allows the labels to change contents.
ps to label contents inspector fix...
Be aware that the HCAddressing has different assumptions about how you distinguish card vs background (group) fields and buttons... If you don't use groups this probably won't matter.
From the documentation dictionary:
=========
"If the HCAddressing property is set to true, expressions in the stack's scripts that refer to fields without specifying card or background are assumed to refer to grouped controls, and expressions that refer to other control types are assumed to refer to card controls. For example, the number of fields reports the number of grouped fields, while button 5 refers to the fifth card button. Also, the values reported by the long or abbreviated name and ID properties of controls include "card" or "background" as the first word, depending on whether the control is part of a group.
"If the HCAddressing property is false, expressions that refer to fields or buttons without specifying card or background are assumed to refer to all fields or buttons. For example, the number of fields reports the total number of card and background fields, and button 5 refers to the fifth button.
"If a stack's HCAddressing property is true, the style property of a button whose style is "menu" reports "popup" instead. This is because HyperCard uses a style setting of "popup" to designate popup menus."
============
From the documentation dictionary:
=========
"If the HCAddressing property is set to true, expressions in the stack's scripts that refer to fields without specifying card or background are assumed to refer to grouped controls, and expressions that refer to other control types are assumed to refer to card controls. For example, the number of fields reports the number of grouped fields, while button 5 refers to the fifth card button. Also, the values reported by the long or abbreviated name and ID properties of controls include "card" or "background" as the first word, depending on whether the control is part of a group.
"If the HCAddressing property is false, expressions that refer to fields or buttons without specifying card or background are assumed to refer to all fields or buttons. For example, the number of fields reports the total number of card and background fields, and button 5 refers to the fifth button.
"If a stack's HCAddressing property is true, the style property of a button whose style is "menu" reports "popup" instead. This is because HyperCard uses a style setting of "popup" to designate popup menus."
============