ArchiCad like "Eyedropper" Tool

VisualARQ
1

Hi VisualARQ team, @fsalla

I am trying to create a custom “Eyedropper” script in Python for a smoother, ArchiCAD-like drafting workflow. The goal is simple: The user clicks for example an existing VisualARQ Wall in the model, the script reads its layer and style, and immediately launches the _vaWall command so the user can continue drawing with that exact same style. (The script should be able to read out all different VA Elements like Beams, Slabs, etc. and maybe even use Polyline when clicking a Curve.. I have to think on that, after some stuff works.)

While reading the style of an existing wall (va.GetProductStyle) works perfectly, there is currently no way to pass this information back to the system to set the active/default style for the next drawing operation.

The Problem:

  1. Command Line limitation: Trying to force the style via a macro like -_vaWall _Style "MyStyleName" fails. The command line immediately expects a start point or the FromCurves option and throws an “Unknown command” error for the style string.

  2. Missing API Method: There is no method in the VisualARQ.Script API to define the active style programmatically before launching the tool.

We currently have to use a workaround where the script pauses, the user draws the wall blindly (with the wrong visual feedback), and the script applies the style via va.SetProductStyle() after the Enter key is pressed. This completely ruins the live visual feedback during the drawing process, which is crucial for BIM modeling.

Feature Request: To make custom drafting workflows and “Eyedropper” tools possible, we would need one of the following solutions:

  1. New API Methods: Something like va.SetActiveStyle(style_id) or va.SetDefaultWallStyle(style_id) that changes the current active style in the UI programmatically.

  2. Command Line Fix: Allow the -_vaWall (and other VA object commands) to accept a _Style parameter via the command line before asking for the insertion point.

Having this functionality would massively speed up the modeling process, as users wouldn’t have to manually search through the style dropdown every time they want to continue drawing an existing wall type.

Thanks in advance for considering this!

PS: I created the text partially with AI, just to let you know.

2

Hi @Sebastian_Wimmer in VisualARQ 4 we have plans to add an option in the command line when you run an object command, which prompts you to select an existing object in the model to copy the same properties (style, dimensions, etc) for the new object. Would that work for you?

We can also consider adding an option in the command line or via API to pick a specific style as well before inserting the object.

As a related information, within the VisualARQ LAB commands there are some for matching properties between VisualARQ objects (height, style, or other named property): Labs - VisualARQ

3

hi @fsalla - thank you for your response.

As of right now, I think making the API as accessible as possible would be the smartest move - One year ago I could not dream about creating functionality I need for rhino on the fly - right now I create scripts on a daily basis in tandem with modelling - just by vibe coding and some creativity to change / improve certain workflows.

with an open API we, the users, can experiment on what we need and then can feed this information back to you to maybe implement things, with a much clearer description because we are able to test things before you, as software developer have to implement or test stuff.

Interesting times,

Best regards,

Sebastian

4

I agree on this. A proper and detailed, Rhino-like API documentation and documentation for developers, for VisualArq, can lead to normal users development of tools and plugins that can elevate their works and VA’s value in the sector of BIM software. +1 from me. Also a 1:1:1 linked relation between VA feature in rhino environment : VA feature in grasshopper environment : VA API functions, is a very important thing that should be a top priority for VA’s future. And it sounds easy development wise, if something is working in rhino environment - such as tag creation - why not to have components for this in grasshopper of API functions and vice versa? Otherwise development wise, we lead to limitations.