It’s been a hectic – but very fun – few days in Munich, working with a group of 60-70 developers from all over Europe who are getting started with Autodesk’s cloud services. I’m particularly focused on those working with AutoCAD I/O, which means probably 5-6 companies in total.
Here’s a quick summary of some of the problems that have come up, many of which are for pure AutoCAD…
Draw Order warning
One developer has a long-running custom operation that presents the following message:
AutoCAD Warning: This operation may take a long time. To greatly improve performance, the system can disregard Draw Order. Disregard Draw Order for this operation?
The fix for this turned out to be simple: setting DRAWORDERCTL to 0 fixed the problem.
UI refresh during long-running operations
Someone experienced an issue with their UI not refreshing: a classic issue with code that keeps the UI thread occupied. I explained a couple of approaches to address this: using async/await to have the compiler package up the additional code and execute it later (my preferred approach, these days) or calling System.Windows.Forms.Application.DoEvents();.
Creating dynamic dimension constraints
Another problem related to generating dimension constraints through code. When these are created via .NET they’re “annotational” by default: the developer wanted them to be “dynamic”, but couldn’t find an API to make this happen. We did find that it could be toggled via the properties window, so I managed to find a way to switch the dimension using COM Automation. To avoid including a type library reference in the project I added a little snippet of code that did this dynamically (yes, an extremely overloaded term in this context):
dynamic obj = dimension.AcadObject;
var dyn = obj.DimConstrForm;
obj.DimConstrForm = true;
What’s a little perturbing is that it didn’t work without the second line, which only reads the dynamic property – not calling it shouldn’t actually change the behaviour of the code, but it turns out to be required. I assume this is a slight quirk based on the fact the property really isn’t a simple Boolean: changing the value does some structural stuff that you can check using ArxDbg. So perhaps getting the property before setting it – which the properties window does, of course – is needed.
Custom AppPackage loading in AutoCAD I/O
On the AutoCAD I/O front we had some interesting times analysing loading issues for custom AppPackages. An important first step is to get the DLL loadable in the Core Console, but that doesn’t always mean it’ll work inside AutoCAD I/O. An important additional step is to make sure the unzipped AppPackage will be found and loaded by the Autoloader: placing it in a local plugin-loading location – such as %appdata%\Autodesk\ApplicationPlugins – should allow you to identify whether the plugin can be Autoloaded properly. If that works locally but fails on AutoCAD I/O, then it gets tricky… one issue we saw, this week, related to dependencies: stripping those out helped allowed the application to load and we could build it back up from there.
There have been some really nice products starting to emerge from the Accelerator, whether using View & Data or AutoCAD I/O. One that I particularly like involves an AutoCAD I/O-based service downloading cadastral data and generating the parcel geometry for download as a DWG file.
It’s really motivating to see so much excitement and interest in using our cloud APIs. People are engaging on real projects that will deliver serious value for their customers. Wonderful to see!
Thankfully it’s not all work and no play, though: here’s a quick snap of a number of us having dinner last night at a Peruvian restaurant in Munich…