PostCommand not working as expected

[grahamcook]

I’m attempting to use the PostCommand to run the FilledRegion command. It gets called from a custom ribbon button. I’m having to get external data from a database prior to posting the command which infleunces the regions parameter values etc. hence the desire to have its own button.  The bear bones code for posting the command is shown below:

[Transaction(TransactionMode.Manual)]
public class PlaceFilledRegion : IExternalCommand
{
    public Result Execute(
        ExternalCommandData commandData,
        ref string message,
        ElementSet elements)
    {
        UIApplication uiapp = commandData.Application;

        RevitCommandId commandId = RevitCommandId.LookupPostableCommandId(PostableCommand.FilledRegion); 

        bool b = uiapp.CanPostCommand(commandId); // returns true
        uiapp.PostCommand(commandId);

        return Result.Succeeded;
    }
}

Nothing actually happens when I click the button. If i debug through the CanPostCommand method returns true and the PostCommand method seems to run with no error. I get the same result on any command that attempts to draw something. If I replace the FilledRegion with the say the Align command however then the Align command gets executed successfully. So the problem seems to be limited to just those commands that create something (i've tried placing Floors, Walls, etc).

The journal does return information that would suggest that there is already some kind of internal transaction running which is preventing the command in question from executing:

Jrn.Command "KeyboardShortcut" , "Create a filled region , ID_OBJECTS_FILLED_REGION"

' 0:< Unnecessary nesting;ArrowUI_4;-1;ID_OBJECTS_FILLED_REGION ;N++EB(NB);

' 4:< FaultyAtomsCheckLog - Comparasion difference found :

' 0:< DBG_INFO: TransactionGroup 17 is being started within existing Transaction 16: line 1347 of d:\ship\2015_px64\source\revit\revitdb\undo\UndoMgr.cpp.

' 0:< <<Begin build CT>>

Is this expected behaviour or have i missed something?  Has anyone one else managed to get these "Create" commands to work through the PostCommand method?  I'm using 2015 with update 7.

Thanks.

Graham Cook

[arnostlobel · Accepted solution]

Hello Graham Cook:

There have been a couple (well, more then a couple, literally) of Revit commands that would not work using the Command-Posting mechanism even though they were officially supported. The problem was indeed related to transaction mechanism, but it is not anything that you may have affected from your add-in (and it is not about the comments you found in the journal, whihc aren't related, fyi). We have fixed the problem for 2016, thus in the currently released version all the commands that are supposed to support posting should work. Unfortunately, the change that was required for the fix was too extensive and cannot be therefore applied to 2015 versions.

Thank you

[arnostlobel]

Hello all,

I am sorry; I have to post a correction, because I was wrong in one very significant point in my previous statement. The fix of many problems with the command posting mechanism has inned been submitted. However, I had an email exchange yesterday with the programmer who made the submission and he told me that - very unfortunately - his team was unable to apply the changes to the R2016 stream. He did not give me details, and I did not ask, but I presume it was due to evaluated risk, since the submission was done rather later in the release cycle. I just assumed there was enough time, but apparently there was not.

That is bad news, really, and I apologize for the confusion and inconvenience. I would be very surprised, however, if the fix is not submitted in the next update release, which presumably will come very soon too. (Please don't ask, I do not have any concrete dates.)

I assume it may come as a surprise to some that I often do not know these very important details like when some fix is actually made available. That is the nature of a large-scale development, though. We, the programmers here work on the main code base (mostly) and there we seen each other's submissions, so we know when something is fixed. However, that is not the end of the process. Very often a fix is not allowed to get to the release branch (or update branch, or subscription branch) base on many criteria, one of which is the level of risk that something else gets broken. We now have so many incremental releases that I simply sometime lose track of which fix goes where, etc. That's just  FYI, for those interested.

[grahamcook]

Just updated Revit 2016 with Service Pack 1 released on the 27 May and the PostCommand is still not working.  Fingers crossed that Update 2 catches the fix!

Graham

[arnostlobel]

I am going to reach out to the developer who told me the fix would be included in the first 2016 update release. Unfortunately, he is in a far different time-zone, so I will not get the answer before tomorrow morning. I'll post what he has to say about this.

By the way, what is the command you wanted to post? I suppose it is actually postable, is it?

[grahamcook]

It was PostableCom​mand.FilledRegion.  uiapp.CanPostCommand(commandId) returns true.

Thanks

[arnostlobel]

Graham,

I have not heard from our guys yet as of this morning. I will report as soon I they reply to me.

Thanks

[arnostlobel]

OK, I have the details. Alas, the fix is not in the just released R1 update. It will be in the very next one, however. As far as I know, it was an honest mistake by the programmer who submitted the change. He did not realize there would be an earlier update release before the one he thought was going to be the first. I know it is important for those who need this feature, but the good news is that it truly had been fixed (I personally saw the code in a review) and it has been submitted into the 2016 branch. So, even though the information mishap is perhaps a little embarrassing, good news is that the fix is coming.

Thanks for understanding.

[grahamcook]

Thanks for looking into that.  At least its on its way which is good news.

[Anonymous]

I tested this PostCommand issue was fixed in Revit 2017. Thank you for your post.