In this image are several blocks that orphaned themselves from their parents.
This has now happened twice in the last 18 hours, in the same app. It was so bad the last time I abandoned the app and went back a checkpoint, and Lo, yet again...
Is this a thing?
I was creating a procedure to add to a list of undo's, and as soon as I added the blue block to insert an item, the orphanaging happened. Also, the procedure added, or replaced other procedures throughout the app causing absolute mayhem. Grr!
I have seen all of a procedure's call blocks puke their parameters when I go back and change the procedure definition's parameters.
It suffers an existential crisis, and rejects its loved ones.
Judging from your emptied out procedure call parameter sockets, I'm guessing that's what happened to you.
This can be avoided if you settle on what your parameters should be before you start calling a procedure.
ABG, I'm glad it isn't just me.
In the last image, the procedure called add_undo is not supposed to be there. It was a procedure called ADD (add any item to any list). It swapped out the procedure in about 2 dozen places, kicking out the parameters and taking over the spot causing general mayhem and dischord.
So you say to name add and name the parameters prior to naming the procedure?
Thanks, thank you so much, this has caused much grief lately.
CHarley
i recreated the procedure, adding the and naming the parameters prior to naming the procedure. I called it put_in_an_undo as opposed to add_undo just in case the word add made the issue.
Now i get run time errors, and after looking into those, with zero warnings displayed at the bottom left, the procedure has over run a different procedure call ADD, the one that adds any item to any list, but instead of letting free the parameters, it keeps only two ignoring the remaining two. I hope that makes sense... see the image...
I now need to go through and locate all the ADD procedures and by changing the name, even though it says put_in_an_undo, it will drop the parameters and show all four that should be resent with the procedure.
Better than having to abandon the entire thing due to 30 odd errors
The order is important ...
- Create the empty procedure
- Change its name to something new and unique
- Add parameters to the newly created procedure
- Code the insides of the procedure, to make sure you have the parameters right
- Pull in calls to the procedure from the Procedures Pallette, as needed.
Never let procedure parameters get out of sync between calls and the procedure definition, or you will foul things up royally.
I think you misunderstood, ABG, AI2 exchanged the blocks, not I.
I am avoiding using any words similar in the procedures, and saving as every few minutes.
If you have an exported .aia file with this bad behavior, post it here for MIT to see.
Some of your parameters look like possible keywords, and there was a bug introduced recently in nb191 making AI2 sensitive to some keywords.
I was thinking that, but then decided to take your advice, and be careful of keywords. Heck, that's a programming newbie 101...LOL
I'm not sure what good examining blocks are anyway, it seems really random, and I cannot (intentionally) cause it.
Thanks for your help though
Charley