Could a Console Application window be a more suitable solution for COGO?
As with QCAD, an API, tend to be Graphically oriented.
COGO not as much so.
Engineers and Surveyors are more exacting with their results than Drafting is within their results.
If so, is it a waste of time to develop a Console (text) Application??
Or perhaps not even possible??
If not possible, then a GUI is the answer. COGO will have found a new home. Just curious. My partner says GUI, I lean towards Console !!
Difficult to answer because we donāt know what the goal is.
And then I mean not in details.
Weāve seen you struggle with simple sample QCAD scripts, but nothing like āI have this data and I want that result.ā
Nowadays most things are more graphically simply because computer graphics evolved very hard and are still evolving fast.
Raw textual data is usually hard to visualise for humans, binary data is even harder to interpret but dedicated code can visualise both with ease.
In reverse, data from a draft can easily be exported in whatever textual or binary style required.
Reading this: Help
Then a so-called āCOGO Input dialog boxā would be easy to implement in QCAD.
Not knowing for sure if that is the goal.
Finally, getting back with you⦠Iām going with the GUI⦠the more modern approach, as your Auto-CAD examples demonstrate.
Beyond that, I am going to Post code for a 5 Column by 1000 row array in JavaScript to store Survey field Points.
The 5 Columns Are:
Point Number
Eastern
Northern
Elevation
Description
We plan to migrate to the C Programming Language, eventually, so I reference cJSON. I suspect you are familiar with the cJSON library. Could come in handy as a STANDARD to read/write/modify the use of JSON in C. cJSON come along with an API.
A list of 1000 points with (Point number, Y, X, Z, Description) can already be imported if presented as CSV:
You can extend QCAD functionality with C++ libraries but natively you work in ECMAScript:
JSON is supported out of the box in ECMAScript ⦠ā**JavaS**cript **O**bject **N**otationā
Built in function for converting JSON strings into JavaScript objects: var object = JSON.parse(jsonTextString);
In reverse: var jsonTextString = JSON.stringify(object);
And very similar for arrays or a mix of things, all within JSON limitations/restrictions.
I stumbled across something that at first was confusing me, now I can see whyā¦
The āprompt methodā was not working as I thought it would with Node.js ā¦
Now I am understanding the issue⦠how to handle user input synchronously in Node.js.
I am seeing synchronous and asynchronous communications as the issue ..
OK, thank you for pointing out the Technology differences between node.js a QCAD. And it is different, very different.
My work around will be to have Utility Functions outside of QCAD, using Node.js, and simple sharing the output data, until a better solution become available. I do this in the interest of filling the gaps in my approach. Perhaps others can find better solutions. We will have results to look at.
I could see Python processing output files that could be useful. I will use any Utility at my disposal.
My first out put file will be a table of a two-dimensional array of point values, that can be manipulated.
Sorry for re Posting⦠Minor update, the file format I will USE is JSON. I have been reading on it, and it is a common interchange format, oriented towards JavaScript (JavaScript Object Notation).
Array based or object based ( [ā¦] or {ā¦})?
Or mixed?
An array of points is easy to iterate.
Creating an RVector for each, at that location an RPoint and adding additional data as custom properties.
You will need to implement a specific QCAD import tool ⦠A script.
The required functionality exceeds the Simple API.
Developing a Console Application for COGO can be practical, offering precision and ease of use. Itās not a waste of time; it caters to a specific audience seeking efficiency. GUI remains an option, but the Console serves a purpose.
But that would leave me building a Console Application in Qt5. That would require some guidance from others to keep me on track. I could still have questions.
And a major issue is my Development Environment.
I am 100 percent Linux, because of cost issues. I am very restricted because of that.
Relocation out of the U.S. is always on the table.
This is moving towards a Console Application in Qt.