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

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.

"TOP" a écrit dans le message de news: snipped-for-privacy@m79g2000cwm.googlegroups.com...

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.

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.

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.

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.

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.

ModelDocExtensi> I really appreciate all of these great comments.