Should SW's API give access to all dialogues boxes & commands?

Being an old VB6, (and before) programmer, I was every excited about
the possibilities of what the API could allow us to automate. However,
when I started working with it, I found a few limitations.

Reciently, I have a programming project that has forced me to upgrade
to VB.NET. As I have started to understand what Objects really are,
(and am still working on this) it is becomming very apparent that the
API is not consistent with OOP, (object oriented programming).

functions that "mirror" some parts of SW that can "interface" only a
few of the objects in the SW. If the API was really an OOP environment
then most of the same functions, commands, dialogues could be
"inherited" through the API WHERE THE PROGRAMMER COULD THEN EXERCISE
THE METHODS AND PROPERTIES, JUST AS THE OPERATOR MAKES SELECTIONS AND
LAUNCHES COMMANDS WHEN USING SW DIRECTLY.

A good example of this could be the hole wizard. If this Object was
available to the API then a "copy" of the hole wizard could be
inherited into the program where all of the properties, (ie. editable
options, selections etc. could be easily "managed" by the program that
would allow for a degree of automation that has not yet been. SW
itself, has a fair amount of automation built into it through
configurations etc. but with all of the commands in SW "exposed"
through the API, I believe that SW could become the most powerful CAD
software on the planet.

A major benefit of having the real "tools" exposed through the API
would be that when a Macro was ran that even the DIALOGUE BOXES AND
SELECTIONS would be recorded.... As programmers we could prompt the
operator for various information and selections and when these were
manipulated and then stuffed into the various selections and then if
the operator was given the opportunity to inspect/alter the selections
in the dialogue inputs before finishing the command a lot more users
would be able to develope automated tasks for SW. As it is now,
recorded "micro's" are missing major parts what the operator actually
selects/does in the SW environment.

Does anyone else agree that every SW command, and dialogue box should
be available in the API? Doesn't it make a lot more sense that a
recorded Macro should record EVERY selection, key stroke etc.?

Ed

 

Reciently, I have a programming project that has forced me to upgrade

You are absolutely true. You should, however, note that SW is not written in
VB.NET and the API is implemented by using COM interfaces. If I have
understood it right, there is no equivalent of "inheritance" in COM, an
object is just implementing a set of interfaces you can call. You can see
that in a very clear way in VB6 (which is designed to be able to create
com/activex components); you can create classes and a class may implement
multiple intefaces, but by definition, there is no such thing as
inheritance.

We cannot see how the very internals of SW has been designed, but even if it
has been programmed using OO, you could not inherit from SW components. I
believe, that many of SW dialogs are still being programmed by using c++,
plain windows api and/or MFC, and that some pieces of SW are written in
procedural spaghetti code instead of OO. Altough the SW api is very useful,
some aspects in the API tend to indicate that the internals of SW are not
very elegant.

That is absolutely true. That would, however, require a very special
architecture. For example, if you would create an inherited version of some
feature - let us say the extrude feature - how would SW know to create your
inherited version instead of the original one?

I believe that enabling the inheritance of SW objects would require
rewriting of the whole SW in eg. c# or vb.net, which I don't believe to
happen during the existence of this universe.

Absolutely, but I doubt that it is never gonna happen...

-h-

 

The API is very limitied. You can go so far and no further. Solution
partners are allowed to go a little further. But not everything is
opened up.

I recorded a macro the other day and a FileFind method was used. This
method is not documented and does not work in a macro if replayed. My
guess is it slipped out. I have always wanted to be able to
programmatically set the configuration of a part in a pattern of parts
in an assembly, but this is not opened up in the API.

In the first version of SW, SW95 the capability was there to record
actions such that they could be played back and reproduce what was just
done.

 

When I see such a good level of example of discussion, solidworks would have
an immediate direct contact with you to improve their product and we could
see the interaction.

On Topica with cosmosm, here and so on for other product..., we often see
very pertinent advices, questions and no direct reactions from the
developpers, helas! This direct interactivity between developpers and
developpers could be very stimulating and exciting on a technical point of
view.

 

Keep in mind that Class Inheritance CAN be achieved if using ANSI C++ .

VB6 did not support True Class Inheritance.
That said, it is still possible to manipulate SW dialogues in VB6 via
the Windows API..

However, .Net, as an architecture, supports Class Inheritance.across the
board.
Keep in mind that .Net is NOT a COM based architecture.

A well kept secret is that VB6 programs can still take advantage of .Net
functionality.
http://msdn.microsoft.com/vbrun/vbfusion/usingnet/default.aspx

If SW stays committed to COM, (as it should in my opinion)
integrating the .Net architecture into the API could be done quite
easily and painlessly.
COM Interop is something that isn't going away any time soon.

What SWCorp really needs to address via the API is exposing all the UI
Events.
This would benefit both the casual developer as well as the seasoned
programmer
by eliminating the need to use the Windows API for retrieving handles
and other functions.

 

I agree. I think the commands should come first and the GUI should
implement them.

 

It's frustrating that SW corp doesn't seem to value input from this group.

PDMWorks needs this as well.

Just about every useful function in PDMWorks can only be done via the
client UI.
It's particularly frustrating when you map DWG block attributes to
Custom Properties
and they only get set if you check in the DWG files from the client UI.
If you check in via the API, no Custom Properties.

One the bright side, Conisio has a very robust API.
I just hope SW doesn't screw it up by trying to "improve" it.

 

It's particularly frustrating when you map DWG block attributes to Custom

This is just one of many things which indicate that some aspects in SW are
not designed quite well. Generally, applications should be designed so that
things are not dependent of the user interface, or at least it is a good way
to go. The UI should be only one way to interact with the software, not a
key part in it's functionality. The SW api shows in many places that some
things are dependent of the very existence of the UI, for example you may
get different behaviour depending on document window visibility (fortunately
this is mentioned in the API help). The most stoopid thing IMO is that you
can get two _different_ and differently behaving ModelDoc2 objects pointing
to same actual model, one when the model window is hidden and another when
the window is visible.

In a well designed software the UI should be just an interface to the
software, but in SW the user interface _is_ the software.

-h-

 

I really appreciate all of these great comments.

1) I wonder if VISTA will have any longterm impact on the dependence
on COM?

2) Obviously I/ we don't have a complete understanding of the inner
workings of SW and why commands and UI objects have not be inhereted,
but I would like to see as many users as possible to begin to request
that "commands" and "UI objects" be exposed by whatever way that the
API has to do this. I don't care how they do this, rewrite the API or
SW or whatever. I do realize that this may never happen but to me this
one issue could have a major long term impact on SW.

3) It totally amazed me that even if there is a C++ command, (or some
other OOP) in the background that uses COM or whatever that there
couldn't be a "fairly" straight forward "interface", (probably a huge
select statement that could internally launch the same command the way
that SW environment does)? This would be equivelent to a phantom
command line. Then this interface could also expose any variables,
methods etc. Perhaps this is too simplistic but again, the bottom line
is that ultimately SW needs to work towards such a capability.

Thanks again for all of the great comments,

Ed

 

FYI the 2007 API allows you to start any command that is available to
the UI.

ModelDocExtension::RunCommand