Passing Argument using ICommandItem.Execute in VBA

[TrevorGrout]

I am working with HecGeoRas and it is a toolbar with a series of commands.  I am able to call these commands using the ICommandItem.Execute via a UID.


Sub ExecuteCmd()
  Dim pUID As New UID
  Dim pCmdItem As ICommandItem
  ' Use the GUID of the Save command
  pUID.Value = "{C3116AF1-F68C-428D-A62B-16F6E0C7A356}"
 
  ' Layer Setup:                              {C3116AF1-F68C-428D-A62B-16F6E0C7A356}
  ' Import Ras Data:                          {4623536F-5B32-4B65-918C-D903A1384A09}
  ' Water Surface Generation:                 {CEB072B7-A420-447C-BF16-12D3F632EDB3}
  ' Water Surface Deliniation Using Rasters:  {ED67C0C3-C9E9-4FD7-9F76-DA833781D8DB}
 
  ' or you can use the ProgID
  ' pUID.Value = "esriArcMapUI.MxFileMenuItem"
  pUID.SubType = 3
  Set pCmdItem = Application.Document.CommandBars.Find(pUID)
  pCmdItem.Execute
End Sub


So my question:  Is there a way to feed arguments after the "pCmdItem.Execute" command so that I can run input the required arguments for this command from code and not interactively.  I have spent hours trying to find a solution and I can't seem to find one.  Also, if there is an easier way to do this in python that would be fine.  If anyone could supply sample code to solve my issue I would appreciate it.

Thanks
Trevor

[EdgarBejarano]

Hi Trevor,

I am trying to picture why a command (an instance of a class that implements ICommand) would have arguments that would need to be passed on to it after its OnClick method has executed, which is what happens when ICommandItem.Execute() is used with that command.  By the time ArcMap opens and displays a command, the code in its OnCreate() and its constructor have already executed, and the class that defines the custom command has already been instantiated.

Do the commands you are executing programmatically with ICommandItem.Execute() open a form/window for user input, and does such input correspond to the arguments you want to pass?  I am trying to picture the argument(s) that such commands would have.

[TrevorGrout]

Hi Trevor,

I am trying to picture why a command (an instance of a class that implements ICommand) would have arguments that would need to be passed on to it after its OnClick method has executed, which is what happens when ICommandItem.Execute() is used with that command.  By the time ArcMap opens and displays a command, the code in its OnCreate() and its constructor have already executed, and the class that defines the custom command has already been instantiated.

Do the commands you are executing programmatically with ICommandItem.Execute() open a form/window for user input, and does such input correspond to the arguments you want to pass?  I am trying to picture the argument(s) that such commands would have.

Thank you for responding.  I am not very versed with ArcObjects and I am trying to feel my way around.  So, if I explained in more detail.  Yes, a window pops up and asks for user input once I run the macro.  I am not having a problem with the code executing.  My question is that instead of a manual input can I code a way to have the toolbar command automatically run with the inputs already filled out. 

So the inputs the popup asks for are locations to input grid and where to save the output and etc.  Normally, the user would enter this information in the popup but I am trying to automate it.   Is this feasible in Vba or can I do this in Python?  I am somewhat versed in programming techniques (matlab) but I am learning ArcObjects and Python.  Another thought is it possible to convert a custom toolbar into a toolbox?  That way I can use modelbuilder and etc and then manipulate the code.    My commands/toolbar are developed by the Army Corps of Engineers and there is no toolbox associated, only a toolbar.

If you think I should post on another forum, please let me know which one might more appropriate.

Thanks
Trevor

[EdgarBejarano]

As I suspected, the commands you execute with ICommandItem::Execute show a window for user input.  I do not think you can programmatically input
data into that window and programmatically "enter".  You see, the command in question has already fulfilled its job which is to display the window.  That
window which displays is an instance of a different class.  It is not an instance of the command's class.  So the window/form you see is a separate object
with its own properties and methods. 

If anything could be done that could possibly automate the process a little more, it would be up to the developer of the command and the window. 
For example, the developer can put default values in the form, but that would still not help.  Had this been a geoprocessing tool (in a toolbox), you
could programmatically input the parameters of the tool and execute the tool in either VBA with ArcObjects or in a Python script/ModelBuilder, just
like you say.  But a command that sits on a toolbar is not a geoprocessing tool (GP Function), and you cannot convert a command into a GP Function.
You would have to develop it in C#, VB.NET, C++ or Java using ArcObjects and make it do the same as the command and for that, you need the
source code of those commands, in the first place.  Perhaps there are already equivalent HecGeoRas geoprocessing tools out there.  I remember having
worked with some of the USACE commands a good while back for drainage/flood studies.

Anyway, programmatically executing a command with ICommandItem::Execute the way you are doing is intended more for those commands that
just do something without showing a form for input, like executing the Full Extent command, which avoids having to use finer-grained ArcObjects
code needed for doing what an existing command already does.

[TrevorGrout]

As I suspected, the commands you execute with ICommandItem::Execute show a window for user input.  I do not think you can programmatically input
data into that window and programmatically "enter".  You see, the command in question has already fulfilled its job which is to display the window.  That
window which displays is an instance of a different class.  It is not an instance of the command's class.  So the window/form you see is a separate object
with its own properties and methods. 

If anything could be done that could possibly automate the process a little more, it would be up to the developer of the command and the window. 
For example, the developer can put default values in the form, but that would still not help.  Had this been a geoprocessing tool (in a toolbox), you
could programmatically input the parameters of the tool and execute the tool in either VBA with ArcObjects or in a Python script/ModelBuilder, just
like you say.  But a command that sits on a toolbar is not a geoprocessing tool (GP Function), and you cannot convert a command into a GP Function.
You would have to develop it in C#, VB.NET, C++ or Java using ArcObjects and make it do the same as the command and for that, you need the
source code of those commands, in the first place.  Perhaps there are already equivalent HecGeoRas geoprocessing tools out there.  I remember having
worked with some of the USACE commands a good while back for drainage/flood studies.

Anyway, programmatically executing a command with ICommandItem::Execute the way you are doing is intended more for those commands that
just do something without showing a form for input, like executing the Full Extent command, which avoids having to use finer-grained ArcObjects
code needed for doing what an existing command already does.

thank you so much.  I was afraid of this being the case.  I will see if there is another way to accomplish my objective.  Your answer made sense and I appreciate your feedback.