WINAPI techniques for geometry selection?

I almost never use WINAPI. I have used it on real projects only a handful of times. But sometimes there is no other way so I have to do it.

And I can do most things I need to do with WINAPI when I have to. I can click buttons and enter text. I can crudely time things to make clicks happen at the right time.

But the one thing I am not satisfied with is selection of geometry.

If there is a single input to a function, a lot of the time you can pre-select it and launch the function and it will work (but not always).

But some functions require selection of multiple objects and it is not clear to me the best way to do this.

Now I have a scheme in my head  to use Center Graph and some user pre-clicking to indicate horizontal position of the tree. And I think with this I can hack a way to position the cursor where I will have a pretty good chance of a selection when faking a mouse click. 

But before I go through all that trouble I thought I would like to ask if anyone knows better way? How do you select geometry when forced to use WINAPI.

As a gift for your answers, I am attaching my WINAPI dialog plotting tool.

This tool is a macro. You enter a dialog caption and all the child windows of the dialog are plotted in a Catia part. Since window ordering of child windows at least seems consistent, it is really easy to determine which child window of a dialog is which (which is the OK button for example).

Since the tool uses UDF's it may require KT1 or PKT to run. However it may not because it uses a Jedi Generative Scripting trick to create the new part and instantiate the UDFs so I am not totally sure the KT1/PKT license restriction applies.

Thanks for any ideas!

Are you trying to add selected geometries to Catia function windows ...

like:

Catia.StartCommand("Projection")

Prompt for selection of the "Projected" Geometries ...

is that it?

That would be a good example. Only using that example, I want to click the "multiple element bag" button and then select multiple features for one side of the intersect. 

Hello All,

To press the [Multiply Elements Bag] button is easy. The caption of the button is PushBMulti and the class is Button.

The displayed |Projected| dialog box contains a Listbox control which just stores strings not the selected objects.

The selected objects(of type SelectionElement) are stored (or shall be added) in a INFITF.Selection object and therefore the opening of the |Projected| dialog is not required.

What are the selection criteria of yours ie how do you know which elements shall be selected?

-GEL

Thanks George,

Yes pressing a button is easy. But I am not actually interested in the intersection function. Obviously that can be done fully within automation and WINAPI is not necessary at all. 

What I am interested in is a specific tool in the Composites Manufacturing workbench which is not exposed for automation.

This tool accepts inputs in a manner similar to the "Selection Bag" tool so I figure if I can do that I can do what I want.

Just adding items to the selection object when the bag dialog is open (mySelection.Add myCurve) does not work. The items must be physically clicked from the tree or from the graphics area for them to be inserted into the list.

I find the elements I need to select by decending through the "Stacking" body (a composites construction) in the tree. 

Do you know if there is a Composite Object Library in the VBA References??

I don't think there are any interfaces exposed for composites. 

Hello Cliff,

1. Is it right if we assume that the [Plies Group] in [Composites Grid Design] Workbench is one of these tools? If not let us know one or two of them.
2. For testing reasons and because we are not familiar with [Composites Grid Design] Workbench, is it possible to upload a simple part with relevant elements you need to programmatically click?

-GEL

Thank you Little. That seems to be the secret. 

Another secret may be DON'T USE VBA. FindWindow and especially EnumChildWindows are extremely unreliable with VBA. I can step through the debugger and everything works right, but then when I run the macro without breaks, EunumChildWindows never returns any of the children. No amount of sleeping and waiting for the dialog to appear can make it work. I put the same code into a VB6 project - so it is external to Catia - and it works no problem. 

Agree on EnumChildWindows, VBA callback functions look very suspicious to me.
Although FindWindow generally work fine, problems occur only with synchronous (with modal windows) commands that "freeze" macro execution. In most cases they can be worked around using a script.

In Reply to Cliff Johnson, Cliff:

Thank you Little. That seems to be the secret. 

Another secret may be DON'T USE VBA. FindWindow and especially EnumChildWindows are extremely unreliable with VBA. I can step through the debugger and everything works right, but then when I run the macro without breaks, EunumChildWindows never returns any of the children. No amount of sleeping and waiting for the dialog to appear can make it work. I put the same code into a VB6 project - so it is external to Catia - and it works no problem. 

Cliff,

Are you running 32bit or 64bit?  My experience is when running 32bit, since CATIA & VBA are both in-process, the dialogs don't update as we send WINAPI commands since the VBA code prevents CATIA from refreshing.  Conversly while in the debugger, stops in the code do allow for refreshing so it appears to work fine but doesn't, as you mentioned, when run outside the debugger.  However on 64bit, CATIA runs natively, but CATIA VBA is emulated in 32bit, as indicated when looking at windows task manager (CATVBAHostingApplication.exe*32 under Process tab in task manager).  Therefore on 64bit OS, CATIA VBA is actually out-process and the dialogs can update while a VBA is running, where as before they could not update.

Anyway, the way I have been able to get the dialogs to update to properly receive WINAPI functions is to use a combination of Sleep (API), DoEvents, and CATIA.RefreshDisplay = True in a loop while waiting for the dialog to appear.  I think CATIA.RefreshDisplay = True may be the key to your situation.

I've had a lot of success with WINAPIs and CATIA dialogs using this technique, as long as my code waits for the proper dialogs to appear by doing the aforementioned loop plus a FindWindow to confirm the dialog has actually appeared.  Previously I would randomly wait a set amount of time for it to appear, but this doesn't make for very robust code since we never know how long each individual workstation will take to perform a task.  Furthermore the loop plus FindWindow option makes the code execute much faster plus the user only sees the dialog for a split second, which I think offers less chance for them to click something and mess it all up.

I have never tried to fulfill a dialog that requires an actual selection of an object from the tree, so I'm curious to know what you come up with.  Hopefully my comments help solve one of your roadblocks vs. something you already know!

Good luck!

-Dave

Thanks for the suggestions. 

I am working on 64-bit WIndows 7.

I tried your suggestions for DoEvents and Catia.Refresh Display but they did not help.

However, I think I have figured out a way to make it work. 

It has been confusing to me because if I launch the dialog myself, I can always perform FindWindow and EnumChildWindows in VBA very reliably.  But if I call Catia.StartCommand  I can perform FindWindow, but EnumChildWindows never seems to work. 

So borrowing a thought from another thread, I make this CATScript file:

Sub CATMain

Call Catia.StartCommand("Intersection")

End Sub

Then I called that script from my VBA using

Catia.SystemService.ExecuteScript("C:\TEMP",catScriptLibraryTypeDirectory,"START_INTERSECTION_COMMAND.CATScript","CATMain",params)

And what do you know after the dialog appears both FindWindow and EnumChildWindows work as expected and I am in business. 

Hi Cliff,

Glad to hear you got it working, too bad an external file is needed.  You have 64bit OS, but is CATIA 64bit as well?  A quick way to check is to look at "Processes" in task manager.  "CNEXT.exe" would indicate 64bit CATIA on a 64bit OS, but "CNEXT.exe *32" would indicate 32bit CATIA on a 64bit OS.

Anyway, a way to avoid using a separate file would be to use a timer.  Look into the "SetTimer" and "KillTimer" WinAPIs.  When I was on 32bit, I made a function that started up a timer, which is inheritantly a loop.  The timer would do a "FindWindow" and perform some action, like enumerate child windows, then call "KillTimer" to end itself.  Its like firing off a new thread to do some other task but everything is contained in one block of code.

Rough Example:

Private lTimerID as Long
Sub CATMain()
 lTimerID = SetTimer(0, 0, 1, AddressOf MyTimerFunction)
 CATIA.StartCommand "Intersection"
End Sub

Private Sub MyTimerFunction(HWnd As Long, Msg As Long, idTimer As Long, dwTime as Long)
 HWnd = FindWindow(vbNullString, "Intersection Definition")
 If HWnd > 0 Then EnumChildWindows HWnd, AddressOf EnumChildProc, ByVal 0&
 lTimerID = KillTimer(0, lTimerID)
End Sub

Private Function EnumChildProc(HWnd As Long, lParam As Long) As Long
 'Your Enum function here...
End Function

I typed this in notepad, so it doesn't work as is but hopefully you get the idea.

-Dave

64bit OS, 64bit Catia..

I worked around the need for an external file by using the Evaluate method instead of ExecuteScript.

Sub OutThreadStartCommand(command As String)    

'execute StartCommand in a different script    

Dim ss 'As SystemService    

Set ss = CATIA.SystemService    

Dim params()    

Dim macro    

macro = "Sub CATMain()" & vbNewLine & _                  

"CATIA.StartCommand(" & Chr(34) & command & Chr(34) & ")" & vbNewLine & _                  

"End Sub"    

Call ss.Evaluate(macro, CATVBScriptLanguage, "CATMain", params)

End Sub