The present Python API is severely limited in that one can not select elements or address labels or AutoText. I have modified my previous AddOn Utility to allow access to these functions. The AddOn demos and makes available several needed functions. My intent is that Graphisoft would incorporate into Python, similar functions. Take a look at the video or try the APX as posted on Github -- listed in the video description. Windows Only.
I'd be interested in any comments or additional functions or how you might use them? If you agree that the Python API needs work, make sure you comment to Graphisoft, together with any ideas for needed capabilities.
I believe that adding additional capabilities would not be that difficult using the AddOn route.or ,perhaps several AddOns of different themes?
Finally the most severe deficiency presently in the Python API is the lack of the ability to display, in Archicad, the results of any Python script, particularly formatted data. We need the ability to create and interact with interactive spreadsheets and formatted (HTML) text boxes for Construction Documentation.
What are your thoughts and how should Graphisoft improve Python -- if any. Now is the time to express your thoughts on this utility ,as a example, and any other needed improvements to data access and documentation in Archicad. Can we get a discussion going?? What do you need/use in your projects?
This interests me as a newb to the Archicad API and C++ but fairly experienced with Python [and several other languages]. When starting in on this I made a conscious decision to focus on the C++ way of doing add-ons. I believed that to provide Python add-ons would require an extensive knowledge of the C++ methods and properties in order to make the translation to Python, if it was available. And the 'if it was available' caveat is what turned my focus towards C++. My reasoning was that if I had to understand the C++ to do the Python, I might as well understand the C++ and everything that it offers instead of a translated subset for the sake of writing in Python. For example, I am very surprised to hear of the selection limitations you mention.
I am reading your post as validation of my decision but am curious to hear your thoughts based on your actual experience with both languages.
i agree with your thought line. At present, Python is too limited to be of much practical value. This is why i am trying to bring the capabilities of the C++ API to Python scripts.
This brings us to your point that if you need a understanding of the C++ API to expand Python -- why learn/use Python -- Good Point. First - Python scripts are limited because Graphisoft's management has reneged on their promise to make it viable for automation, but the ground work is in place to make this feasible. if Graphisoft has decided not to do that, it fails on the users to do so. I again agree with your point that the average project manager does not have the skills to do so. SO WHY BOTHER??
However, lets assume Python scripts will have the nearly the same power/capability as the C++API functions -- for now.
Python's performance will be about 10 times slower than a C++ function, but this is not a issue with a manually initialed function as the time to find and click the command would still be longer than then return value. And the wait time of a few seconds is not significant to see data results.
The advantage is that Python's program development can be 10 times faster than C++. Python's language is easy to understand and document. Because the script in interpreted, you can quickly reload and see results in real time without having to re-compile and reload AddOns, which is time consuming. You can quickly decipher types and values and make adjustments in seconds.Eliminating bugs is therefore very easy to do.
Python has access to hundreds of additional libraries in which to process, store, analyze and display data, including access to the most popular programs.
The C++ API is very difficult to understand. A understanding of the C++language is not enough. Graphisoft makes extensive use of DEFINES, Typedefs and Macros to simplify its programming. it uses three favors of string types which you are constantly converting. Plus multiple casts to different data types. Few of this is explained as it is assume your can research the files yourself, Many of the examples are too basic in nature or wrong. Python eliminates all these problems , except for speed.
The problem is Python present limited capabilities. However, i have found that it is possible to make available, the C++ API examples to Python Scripts through the use of the ExecuteCommand handler interface. This effort is huge but not difficult and that is what i am attempting to do -- as time permits.
You may want to watch the video, with a simple Python command, and some input parameters, one can execute the same functions as demoed in the C++ examples at a minimum of development time.
Finally Python has limited ability to write the results back to a Archicad plan such as Spreadsheets or formatted multi - column data. This must be addressed or Python will still be mostly worthless. Graphisoft has indicated that they are open to suggestions, but i have seen no movement or sincerity to date. That's why more user input is needed. What are your thoughts??
It is very much a surprise that GS is leaving it up to the users to 'bring the capabilities of the C++ API to Python scripts' and sounds like they were a little too anxious to release it. Or released it only for the sake of releasing it - <sarcasm> "Heeeere's your Python" </sarcasm>. Kudos to you for filling in those blanks. Traditionally - and I am talking about the AutoCAD world - the user base of programmers helped determine the next built in features of the software. But that was for software features, not the API to develop those features.
I totally understand the speed factor of development time and overall forgiveness the Python development process has. I work in a larger firm [about 55 users] and my role is dedicated to app development for BIM, Office products, and sys admin. In a way, it is my job to R&D the right tools for the right task, which is why I am juggling 8 or 10 languages. The point being is I'm not afraid to learn. That makes the struggles with C++ a little more bearable. And I realize this is rather unique among the typical Archicad user base that dabbles in any kind of development.
I can't wait to check out the video and and further address this issue with the benefit of that information.