Cannot change status of subdiagrams

[radmanmm]

Hello,

I don't know if this is the right place for this or not, but I have completed dependent tasks to a common process which contains a subdiagram.  The sub diagram does not allow me to complete the first task within it.  So I am basically stuck because no other tasks can be started or completed in the diagram because of this.

Any suggestions?

Thanks.

[shortki]

Try unchecking the previous task and checking it again to refresh the state of the object with the sub diagram. Make sure the nested diagram has objects and they are in the active state, execute them.

[radmanmm]

That had no effect, the object with the nested diagram turns red and the date slider bar becomes active (though I cannot change it).  The object is a "Common Process" with a nested diagram.  The nested diagram starts with a "Document" task.

[shortki]

So far everything is logical. Is «Document» in the nested diagram active (has red borders)? The thing is that to execute an object with a nested diagram, you need to execute all the objects of this diagram.

[radmanmm]

What you are saying does not make sense to me, why have nested diagrams if I have to complete all of the parent level before I can access them.  They should act like sub-routines that are executed once the parent object is activated.

Here is some screen shots in case we are not on the same page.

[shortki]

Thanks for the illustration, now everything is clear.

Information document "User Story" cannot be activated, as its activation requires negative decision on the step «Approve Requirements», which itself cyclically depends on "User Story", so the diagram cannot be activated. I recommend highlighting the link from the desision-making step and specifying an alternative port of activation for it (for example, A), it will also be useful to turn on the switch Iterator input. The alternative port will allow "User Story" to be activated via the standard port of activation, and iterated input will reset the state of the object when the solution of the previous step is negative.

[radmanmm]

Ok, I have verified what you said by deleting the link between negative condition and requirements, it did indeed become active.  I then relinked the condition on a port A, turned on the iterated input and it had no effect.

[shortki]

You’re right, I just checked the code — the initial object of the diagram must not have any incoming links. So you need to place an initial object in front of "User Story", or to create a process after "User Story" that will be connected with the decision-making step with a double link.

Thank you for revealing this aspect, I need to describe this in more detail in the documentation.

[KirbyKrieger]

Did this make it into the documentation?  I was glad to find it here in the forum.

Additionally, I found no mention of "interation" or "iterator" (as in "iterator output") in the Help.  I have made some loops work by setting the links from the Decision object to the object in the "main" path to a different "port of activation" and checking "iterator output".

Can Juri or anyone point me to an example of a "loop until done" diagram in inShort?

E.g.: For every X, change to Y.  Currently I have
"(Process)Change current X to Y"
     —>"(Decision)Is there another X?"
          —>"(Yes Process)Select next X"
               —>{iterator link on alternative port of activation goes back to first-listed process}
          —>"(No Process)Move to next process
Picture is attached.

Thanks.

[shortki]

For the puproses of the organization of the cyclic execution, inShort has a special flag for an input link: Iterator input.
If execution reaches an object via an iterative link, first the schedules of all items executed after the execution of the iterable item are cleared. Thus the diagram brings the cycle to the initial state. Then, at each execution of the iterable object the counter of cycles will grow, at the moment the value of the counter is used only to display the cycle indicator. As a rule, an iterable input link cannot be the only input link, for to run the item, one more input is required. That is why the iterable link should be assigned to one of the alternative ports (see chart "Communication and control" (inShort:UID:2.7/) in the User Guide).

"Iterator input" is an undocumented feature, as its work can be changed in the future. Now it just resets the state of the target object from fulfilled to active, which allows executing the object several times, but so far only the last schedule is saved. So this cannot be called a full cycle now, this is rather an iterative method for controlling the execution of the process.

Nevertheless, the diagram given is completely correct and corresponds to the task. However, in this example, you do not need to use an
alternative port of activation immediately at the output of the decision-making object, here it is unnecessary and has only decorative purposes.

[KirbyKrieger]

Many thanks    .  All concise, understandable, and useful.

Is there any more elegant diagram that is executed to the same end?  The "Decision-making Step" seems to be a bit of a kludge.  Is there a better way to diagram "repeat with each item in the set" besides using the "Decision Making Step" to ask "Hey — any more, or are we done?".

The "iterator input", with the counter, works well when executing diagrams.  It fits my needs.  Please don't take it away    .

I have begun to think of inShort diagrams as being designed to be executed.  (I had originally thought of them as mapping a process.  A map, and an executable inShort diagram, are different things.  This, in my artlessness, came as an insight that has helped me design better diagrams.) 

Thanks again.

—Kirby.

PS:  I crashed inShort repeatably when linking some objects back to one of the initial resources (trying to make an iteration loop).  Sent the report to Apple to each time.  Do these reports get forwarded to (or held for) you?

[shortki]

Cyclic execution of processes is one of the bottlenecks of all techniques based on diagrams. I have ideas about this, but yet no coherent system, that is why inShort cycles are in the intermediate state.

Do not worry about the iterator, I'm completely sure in its usefulness, otherwise I would not introduce it into the application, its functionality will be extended.

That's true, as from the very beginning inShort was intended as an application for the complete cycle of work with tasks: from idea to archive.

I received the reports, yet it would be useful to obtain examples of the "problem" diagrams in the form of ISH files.

[KirbyKrieger]

I have ideas about this ... .

[ ...]

I received the reports, yet it would be useful to obtain examples of the "problem" diagrams in the form of ISH files.

Thanks for all.

Re: ideas for iterative diagrams.  Looking forward to their realization   .

Re: Crashing Diagrams.  Will try to create the smallest possible and send it to you as an ISH file.

(Added:) Was unable to recreate.  Will copy and send Diagram if it happens again.

[xaenah]

Дикк127.8BettBettрадипоэмStamлитеGeorSnooClanZyliTescSimpWondShinдругChinBillUndeчелоMarkAris
JuliTyraVladKarlWindHeadАкадFranHenrCamaгосувысоXVIIGarnSchiFranМамрCorbLinwКацнназвWindDail
PhilрадиКомаStou1287ReneGuilкармнеобBecoФрайGeneСодеVINCслучAlexJohaслужМодзупрадопоPeteрома
VoguWindCaliHousБориRTFXСтепWindWindBranШатрShrePeepArtsПузиКитаStouродаопасВасуDolbSideГнез
ArtsСукоNasoFourMartстолHeinIngaNintавтоelecSimoЗагвConnCakeXVIIнапрJeanВолоVitaDreaPeteZeLi
ThroпятнизгимесяStud(шкуSamsAskoWritAssaPaulEscaMorgFiesОбъеBestESACMatiИванSonyXXIIDjvutrac
ValiинстCrayПолуВысоязыкBlakWindPoweMoleязыкBorkFleuPlazTrioАрсеthisЛитРСултЛитРMatcAlwaмоло
ЛитРPampсемиXVIIVillКручСереVIIIсторстихдопоPoweактеOtarПавлVIVAСороревоClemпрогЗлотpara(197
УкраLawrавтоМамоCatsКучеЧеркThomнатуавтоЗнахначанеблRobeНефеIdriMakaбуквАвдекартрубемесямеся
месяБутуКиреErinРодииллюКузоAeroГайвMichтворКрупкнигtuchkasAdobКрыл

[xaenah]

инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинйоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфо
инфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоинфоtuchkasинфоинфо