Re: odd stack corruption
On 6/14/11 3:43 PM, Jeff Reynolds wrote: in the end i rebuilt the whole group and the behavior went away, so it was something odd in that group that popped in in the last 5 years or so w/o any edits being done to that card. the odd show the other group behavior only showed up when the stack went to v4.6 livecode, but the mysterious non edit selectablitiy was there all along. i have tried to keep all the code pretty centralized in called handlers to keep careful track of all pieces in it as its got to be very robust. Im hoping all is now fine, I think remaking the group should fix it. After reading your description I suspect it was a conversion problem in the engine. I have often had similar things happen with buttons when I open HyperCard stacks for conversion. The button type doesn't get set correctly and often I need to just remake it. The file format of stacks changed in version 2.7 and it may be that some of your fields didn't come over intact. That's about all I can think of. But re-doing the group should solve it, I think you're safe. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: odd stack corruption
Jacqueline, thanks, thats what i thought with corruption that it would be much more dramatic than this. here are the odd things though that still dont fit. all groups were named uniquely. a) this particular card and its groups (groups not used on any other cards) were created in probably rev 2.6.1 or earlier before (maybe mc as i need to look back at the old archives to see when this card/ exhibit was added) the selectgroupcontrols was implemented and not touched since. you are right selectgroupcontrols was turned on somehow even though i did not when i built it as it does not need that feature and was not in the system when i built it. But turning it off does not have any effect with the odd behavior or either not being able to edit the group or select it in edit mode (other than from selecting from the application browser) or the odd making the other group shown when clicking in the one odd rectangle area in the top left of the screen b) if i go back and look at the stack in 2.6.1 (older versions) the group shows the opposite behavior in edit mode that either in select grouped or ungroup you can only select individual objects, never the group. again you can select the group from application browser. c) there is no feature i think that would make a group always fire (ie act like it was in runtime mode for mouse up/down) in edit mode and not be selectable in edit mode at all? d) i went through all scripts that were in the stack that could show the group which gets show by mousedown the odd rectangle area and commented out the show that group. still gets shown with that click. its almost like there is a front script running that is doing it as its fired before the script in the buttons under this area are fired. e) i went through every object on the card to see if it was in the area of the odd rectangle hot area and nothing lined up with it at all. f) turning off messages only stops the scripts from firing in edit mode but does not allow the groups or its object from being selected with the pointer in edit mode. all other groups on the card behave as they should. f) while i was deleting all the old group objects one button displayed the groups' behavior of being active for mouse down/up in edit mode so you could not select it in edit mode. again i was able to select it through the application browser and delete it. in the end i rebuilt the whole group and the behavior went away, so it was something odd in that group that popped in in the last 5 years or so w/o any edits being done to that card. the odd show the other group behavior only showed up when the stack went to v4.6 livecode, but the mysterious non edit selectablitiy was there all along. i have tried to keep all the code pretty centralized in called handlers to keep careful track of all pieces in it as its got to be very robust. Im hoping all is now fine, this was just a really odd behavior that i had never seen in 26 years of xtalk programming in HC, plus, supercard, toolbook, mc, rev, livecode. but this stack is now i think 15 years old and has migrated through all the metacard/rev versions, so something might have slipped in there somewhere. all is functioning fine now so i hope im good for the future. thanks mucho, jeff On Jun 13, 2011, at 6:55 AM, use-livecode-requ...@lists.runrev.com wrote: It doesn't sound like corruption, it sounds like the group's selectGroupedControls property has been turned off. This is a new- ish property that allows a group to behave as a single object. To edit the group elements, turn that property back on and its individual objects will become selectable again. I'm not sure about the other behavior you describe, where visibility of two groups changes, but I'm pretty sure there must be a logical explanation. Corruption in stacks is not only very rare, but usually displays as crashes, inability to access a card, or something similar. I've never heard of corruption changing object behavior. Make sure your two groups have different names, or that you are referring to them by a unique reference like their number or ID. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
odd stack corruption
ok, this is one of the few times i have ever run into stack corruption in all my years with hypercard, metacard, rev, livecode... I have a application for an exhibit that started way back in the early metacard days thats been running and evolving for years now. this last update i also reved the stack up to 461 as well with a major upgrade to one of the exhibit. then i found a really odd situation with one card where two groups were interacting oddly. a click in one strange area on one group was causing the other hidden group to be show. there were no buttons or scripts that could get fired in that area to do this show at all. it was also an odd rectangle that lined up with nothing in the interact or would show up in the application browser as some old thing left behind. then i tried to go to edit the group that was causing the other to be show and in edit mode in select objects or select grouped if you clicked on any element of the group it would not select it, but it would behave as if in run mode. i could select the group or any of its objects from the application browser. i tired ungrouping and then regrouping, but any regrouping combination i tried with various parts of the old group would create a new group that would instantly be given the old group name and behavior. finally i just reconstructed the group from newly created objects and that new group behaved normally. when i went to delete the old ungrouped objects of the old group i found they all behaved as normal objects except one that behaved like the old group, not being able to select it with the pointer and it still in run mode when the when i was in authoring mode. once all the old stuff was gone and the new group there and working everything seem to then work fine. i went back through old versions over the last 7 or so years in earlier versions and i found the corruption seems to have been there for a long time with the non editable nature, but the odd showing of the other group on clicking in one odd area only comes in when the stack moves to 461. question is should i be worried about the rest of the stack? has anyone seen behavior like this before? should i just keep letting it solder on until something else breaks? this application has been a trooper since the mid 90s running the auditorium presentations at the monterey bay aquarium. its grown from one exhibit on deep sea exploration to 3 over the years and worked with all sorts of equipment, never failing. want to keep this moving into the future, but am loathe to recreate the whole software as it represents a large amount of development time over the years and also runs very specific equipment that is hard to test if im not on site. suggestions welcome. thanks jeff ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: odd stack corruption
On 6/12/11 2:19 AM, Jeff Reynolds wrote: then i tried to go to edit the group that was causing the other to be show and in edit mode in select objects or select grouped if you clicked on any element of the group it would not select it, but it would behave as if in run mode. It doesn't sound like corruption, it sounds like the group's selectGroupedControls property has been turned off. This is a new-ish property that allows a group to behave as a single object. To edit the group elements, turn that property back on and its individual objects will become selectable again. I'm not sure about the other behavior you describe, where visibility of two groups changes, but I'm pretty sure there must be a logical explanation. Corruption in stacks is not only very rare, but usually displays as crashes, inability to access a card, or something similar. I've never heard of corruption changing object behavior. Make sure your two groups have different names, or that you are referring to them by a unique reference like their number or ID. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
