Change the system type for pipe creation via UI

[sniMD547]

Hello,

when you create a pipe via the UI, you can select the system type used for the creation in the settings of the pipe. (If you then create the pipe or not, doesn't matter, the selected type is saved within the document and used as default whenever you decide to create a pipe until you change it again). 

I found out that this setting is saved with the document but I can't pinpoint the location, and I also can't find a way to change it via API which is what I have to do. Does anybody know a way? 

I also have to change the cross-section parameters and the offset. For clarification, I attached an image of the settingsshown when the command to create a pipe is called, and marked the settings of interest.

Thank you!

[sniMD547]

Thank you for the clarification, @jeremytammik. I just don't understand what you mean with the at least two solutions. Do you mean the pipe creation methods?

Too bad that there is no way to get to the pipe system type. But fortunately, the way @matthew_taylor using "Create Similar" suggested works, aside from the problem that I have yet to figure out how to delete the temporary pipe I am creating.

I am not sure how it works with "Accept as solution". Jeremys post answers my question but matts post offers an alternative solution...

[jeremytammik]

Dear Sascha,

Yes, I meant the pipe creation methods.

Yes, too bad, if that is the way it is.

There are several easy ways to delete elements.

One, of course, is to use the document Delete method.

However, if you say 'temporary', then an even easier way is probably to use the temporary transaction trick:

Simply open a transaction, create your temporary object, retrieve the required data, and roll back the transaction without committing int.

In some cases, the data is not available before committing the transaction.

In that case, move one level up: encapsulate the transaction in a transaction group, commit the transaction, retrieve the required data, and roll back the transaction group without committing it.

Some examples of its use are listed in The Building Coder topic group on Handling Transactions and Transaction Groups:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.53

You can accept as many solutions as you like. Everything that helps can be marked as an accepted solution.

Cheers,

Jeremy

[sniMD547]

Dear Jeremy,

the problem with the deletion of the temporary pipe is that it has to exist as long as the user is drawing the similar pipes. And that is activated with a PostCommand. That means, as far as I understand it, that my code is finished once the command is started. And as far as I know, I can't trigger another command to delete the pipe after all the pipes are created. I hope I am wrong ;). At the moment, I collect the Ids of the temporary created pipes and delete them when the user hits a "clean" button. But that's not very practical.

I tried using the transaction group but that results in the pipe being deleted before the user is prompted to create the (similar) pipes.

[jeremytammik]

Dear Sascha,

That does indeed sound quite advanced and complex.

If you have it up and running reliably, though, why not add another little twist, make it yet more complex, and solve this last remaining issue?

1. You create your temporary pipe P0 that you wish to have removed.
2. You enter the PostCommand loop and have no more control while new pipes P1 to Pn are created.

You access P0 to determine specific information from it for the creation of P1 to Pn, correct?

Ah yes, this mysterious inaccessible "pipe system type" PST, huh?

Well, instead of creating all of P1..Pn by using 'create similar' to P0, how about adding a dynamic model updater DMU or probably simpler still, a DocumentChanged event handler to delete P0 as soon as P1 has been created, and use 'create similar' to grab the information from P(i-1) when creating Pi?

Ah yes, DocumentChanged is read-only, so you could use that to grab the information, but not to modify anything, e.g., you cannot delete P0 using that.

But even so, simpler still, I thought you just need P0 to access the PST. That remains unaffected when P0 is deleted, does it not? So why not use the temporary transaction trick to create P0, grab the required PST info, and delete P0 right away. Does the deletion of P0 affect PST?

Oh, and when you say, "I can't trigger another command to delete the pipe after all the pipes are created", I do indeed believe you are wrong.

You could, for instance, implement a DMU to check what is happening and react as soon as pipes are no longer being created to delete P0.

There are probably other methods as well to be notified when the PostCommand and pipe creation has finished.

Isn't the DocumentChanged command triggered after the end of the command?

I am certain that people have devised numerous ways to determine that a command terminated.

You can watch the journal file, subscribe to the progress bar messages, and more.

Oh, and you can subscribe to the Idling event. It will be called after the PostCommand terminates.

Here are some other hints:

http://thebuildingcoder.typepad.com/blog/2015/10/postcommand-causes-internal-exceptions-a-break.html

Interesting discussion!

Let’s get this nailed!

Cheers,

Jeremy

[sniMD547]

Dear Jeremy,

the temporary pipe serves as a template to create similar pipes. So it's not just the pipe system type I need but the pipe itself. I wanted to get respectively set the default pipe system type before in order to use the pipe creation command but since that is not possible, I create the temporary pipe with the desired pipe system type.

Just after I posted my last answer, I remembered the SDK and found the PostCommandWorkflow sample. I'm trying to understand it hoping that I can apply it to my problem. So far, it seems that it is possible to post one command and be back in business after it is completed to post another one. And that would be what I need.

The DocumentChanged is triggered every time the user finishes drawing a pipe, not only when he escapes the whole pipe creating process.

Subscribing to the Idling Event could be the solution.

I'll try it and keep you informed.

[matthew_taylor]

Hi @jeremytammik,

I agree, let's get this nailed. It must be a frustration for others also.

Hi @sniMD547,

I think you may be able to use a combination of the ideas I had.

1. Add an application level updater to detect newly created pipes. Have it turned off by default.
2. In your external command.
• At the start of this macro, search for and delete any temporary pipes.
• Create your temporary pipe.
• Turn the updater on.
• Trigger create similar using postcommand.
3. The user adds pipes.
4. Once the first pipe has been added, the updater will fire. Use the updater to search for and delete your temporary pipe(s), then turn itself off.

The only issues I see are:

• The pipe creation (via create similar) may be cancelled without creating a pipe, therefore the updater won't fire.
• The pipe creation may be undone, and leave the temporary pipe remaining.

@jeremytammik

Not ideal, but most solutions I think of have the same issue.

The only solution I can think of (and I'm not sure it's even possible), is to somehow undo both the temporary and the create similar commands, and recreate the pipes from scratch using the API.

Cheers,

-Matt

[sniMD547]

@matthew_taylor: I tried your solution, and aside from the mentioned issues, it works perfectly. If I figure out how to solve the issues, if that is possible, I'll write about it here.

Jeremy mentioned one other possible solution: let the user draw some lines representing the pipes, and after he is finished, replace the lines with the pipes. And for the line creation, I guess, I wouldn't need the PostCommand, but it has other problems.

Thanks very much for the help! @matthew_taylor and @jeremytammik .