QCAD Bugtracker

Support for external references (XREF)

Andrew,

Bitmap entities can not be cropped by QCAD.
There are no properties to store the reference points of the cropped area.
The cropping area is not limited to a rectangular area.
Image entities at an angle are even more complex to handle.

In all, CLR rejects selected image entities at this stage.

Regards,
CVH

Andrew,

Reported for QCAD 3.32.3 Win10, replicated on Win7.

In your reply to user DerekGove you state:

• After the measurement, QCAD inserts the variable into the command line (e.g. d1). You can then confirm that value in the command line by pressing the enter key.

This is not entirely correct.
The focus should be on the Command Line before pressing the enter key.
Not an issue when inserting a variable in a tool option field. Evaluated on the fly.

Using IP to take some measurement the focus is shifted to the drawing panel.
Then hitting ENTER simply restarts the latest command or ‘arcc’ and no Arc entity is created with the previous active tool (also ‘arcc’).

Hitting the Space-Bar followed by ENTER may do the job.
Assumed to be the intended behavior ... Verified in QCAD 3.26.7

Your cursor is probably still nearby the second point of measurement ... Or not at all.
Hitting the Space-Bar followed by ENTER results in an Arc preview with seemingly a very arbitrary radius but finally repeatable depending the actual cursor position.

Steps to replicate:
- Start QCAD 3.32.3 with a new empty file (In mm over here).
- Start AR.
- Indicate center at (0.0, 0.0).
- R-Click on Command Line input field > opt for ‘Insert Measurement’ > opt for IP.
- Indicate a measurement point at (100.0, 0.0).
- Indicate a second measurement point at (90.0, 20.0) ...
... What is 22.360679774997896964091736687313 units apart.
... IP inserts the variable ‘d1’ on the Command Line.
- Ensure that your cursor is left very near this second point, snapped ...
... And even release the mouse device.
- Hit the Space-Bar.
- Hit the ENTER key or the Return key.
- Move your cursor a little to see a preview of the Arc.

This preview passes through the second point of measurement. Almost but not exact.
And has a radius of 92.19544457 units » Repeatable.

- Do just the same for the next Arc but leave your cursor near (80.0, 20.0).

This preview does NOT pass through the second point of measurement NOR through the indicated point. It has a radius of 85.6605063 units » Repeatable.

- Repeat but leave your cursor near (70.0, 20.0) → Radius of 82.33442756 units.
- Repeat but near (60.0, 20.0) → Radius of 80.62257748 units.

Any mathematical relationships eludes me.

Typing ‘=d1’ in the Command Line returns 22.360679774998 with 12 decimal digits.
The same is reported for subsequent identical measurements d(2-4).

Regards,
CVH

It would be handy to know which toolbar is what, which toolbar we are dragging.

Or which (Empty) toolbar is floating over the GUI drawing area.
Please refer to this forum post.

Regards,
CVH

It would be great if it were possible to import GeoTIFF files into QCAD with their specific geolocation. Currently, they lose their position and size during import. It would be a very valuable feature and probably not too difficult to implement.

In the QCAD forum I had a discussion about that topic with CVH and he had some valuable insights which I like to cite here:

“[...] Since we can create Map Tiles from drawing data (Tutorial) it would indeed be beneficial that bitmap data could be imported correctly. Because the GeoTIFF format is fully compliant with TIFF 6.0 it is simply imported as a bitmap.
The question remains if QCAD is really fit to use it as a GIS application. I assume that one can extract the left lower position and scale by other means. With the corner positions for example it should be possible to scale and place the bitmap correctly.
Then it should be as simple as adapting the Bitmap entity properties in the Property Editor after insertion.”

Regards,
Sven

See https://www.qcad.org/rsforum/viewtopic.php?f=33&t=11757

Andrew,

Latest Trial version on Windows 7 32bit
QCAD Professional Trial 3.32.3 / Qt 5.13.2 / Windows i386
Detected in debugger mode.

In updatePreview an array with shapes to preview is queried with this.getAuxPreview().
These shapes are added to the preview with di.addAuxShapeToPreview(arrayItem).

It seems that the resulting object(s) in previewShapes can be an array of RShape objects.
Then addAuxShapeToPreview fails with an array instead of singular RShape object.

Most probably related to  FS#2605 

Regards,
CVH

Andrew,

Related to this forum topic with the attached file as example.
Tested on Win7 32 bit.

Open drawing as is.
Try:
- Drawing Preferences .. Layout .. Viewports .. Four: Equal » OK
- Menu File .. Revert » Acknowledge warning dialog: All changes will be lost!

There are still 4 GUI Viewports visible.
Check Drawing Preferences .. Layout .. Viewports » Reports one single Viewport.

OK won’t update to a single as no changes are assumed.
One can fix the current state by selecting another configuration and then a single again.

A difference spotted against v3.27.6.0 is that the border of the active Viewport turned dark blue before. This is not seen in the latest stable release.

Regards,
CVH

Andrew,

Related to this forum topic with the attached file as example.
Tested on Win7 32 bit.

Drawing Preferences .. General .. Grid .. Display Grid Y/N is not reflected in the GUI.
But changing the Grid visibility with GR is reflected back in the Drawing Preferences.

Per GUI Viewport:
It is thus possible to set the preference to yes without that the grid is showing.
Or clearing the preference with a visible Grid and then it remains visible.

Regards,
CVH

Andrew,

Still Writing most of my code on v3.27.0 and adapt that to newer resources.

Detected a difference in the latest version while adding entities with an interactive tool.
On v3.27.0 getAuxPreview shapes are Dashed-Dotted in color #7976c5 and displayed above existent entities and under the shapes to create in preview mode.

On 3.32.2 the auxiliary shapes are above the shapes to create in preview mode.

Where both fall together an entity to create as continuous looks like dashed.
For example: An auxiliary circle masks the arc that is being constructed.
Or an auxiliary ray masks a new line segment.

I liked the looks of things to be clearer under v3.27.0.
The preview of new entities are then as intended by the Linetype attribute.

The order of how things are send has not changed in EAction,
In updatePreview new entities come first.
Auxiliary shapes always come second.
Highlighted third.

Regards,
CVH

QCAD/CAM 3.32.2 / Qt 6.6.0 / macOS arm64 / cocoa

After Nesting multiple solutions are shown in the table. Buts the graphical position of the objects are shown incomplete, so it is hard to decide the best choice.
1) screen shot showing the table and the graphics incomplete.
2) screen shot after choosing show the complete nesting result.
3) QCAD file where I applied nesting

QCAD/CAM 3.32.2 / Qt 6.6.0 / macOS arm64 / cocoa

If QCAD starts on extended screen of my macBook no menus are loaded, window is empty (see attached file).
Picking the empty window and moving it to integrated screen will show the menus.

Andrew,

See related forum topic in the International Forums, Deutsch.

User ‘dijs’ reports:
QCAD Professional Trial Version 3.32.2.0 (3.32.2)
M1-Max-Mac Sequoia 15.4.

Using the Library Browser somehow corrupts the QCAD config file.
Closing and restarting the application fails.

QCAD start up as new when deleting the config file or with only removing the entry:

[Appearance] DockappWindows="@ByteArray(…)"

The corrupted line seems to be much shorter: 6k vs 17k characters in my case.

DockappWindows="@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x3\0\0\0\0\0\0\0\0\0\0\0\0\xfc\x2\0\0\0\x1\xfb\0\0\0\x1c\0T\0o\0o\0l\0M\0\x61\0t\0r\0i\0x\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0u\0\xff\xff\xff\0\0\0\x1\0\0\x1#\0\0\x4\xf0\xfc\x2\0\0\0\n\xfb\0\0\0\x1a\0\x42\0l\0o\0\x63\0k\0L\0i\0s\0t\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0z\0\xff\xff\xff\xfb\0\0\0\x1a\0L\0\x61\0y\0\x65\0r\0L\0i\0s\0t\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\xfb\0\0\0$\0P\0r\0o\0p\0\x65\0r\0t\0y\0\x45\0\x64\0i\0t\0o\0r\0\x44\0o\0\x63\0k\x1\0\0\0N\0\0\x1\x87\0\0\0`\0\xff\xff\xff\xfb\0\0\0&\0\x45\0\x63\0m\0\x61\0S\0\x63\0r\0i\0p\0t\0S\0h\0\x65\0l\0l\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0-\0\xff\xff\xfe\xfb\0\0\0(\0\x43\0l\0i\0p\0\x62\0o\0\x61\0r\0\x64\0\x44\0i\0s\0p\0l\0\x61\0y\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\x16\0\xff\xff\xff\xfb\0\0\0 \0L\0\x61\0y\0\x65\0r\0L\0i\0s\0t\0P\0r\0o\0\x44\0o\0\x63\0k\x1\0\0\x1\xd6\0\0\0\xe6\0\0\0z\0\xff\xff\xff\xfb\0\0\0$\0L\0i\0\x62\0r\0\x61\0r\0y\0\x42\0r\0o\0w\0s\0\x65\0r\0\x44\0o\0\x63\0k\x1\0\0\x2\xbd\0\0\x1T\0\0\x1&\0\xff\xff\xff\xfb\0\0\0&\0S\0\x65\0l\0\x65\0\x63\0t\0i\0o\0n\0\x46\0i\0l\0t\0\x65\0r\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\xff\0\xff\xff\xff\xfb\0\0\0\x18\0V\0i\0\x65\0w\0L\0i\0s\0t\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0z\0\xff\xff\xff\xfb\xff\xff\xff\xff\x1\0\0\x4\x12\0\0\x1,\0\0\x1,\0\xff\xff\xff\0\0\0\x3\0\0\b2\0\0\0\x43\xfc\x1\0\0\0\x1\xfb\0\0\0\x1e\0\x43\0o\0m\0m\0\x61\0n\0\x64\0L\0i\0n\0\x65\0\x44\0o\0\x63\0k\x1\0\0\0R\0\0\b2\0\0\0\x10\0\xff\xff\xff\0\0\b2\0\0\x4\xac\0\0\0\x1\0\0\0\x2\0\0\0\x1\0\0\0\x2\xfc\0\0\0\x4\0\0\0\0\0\0\0\x1\0\0\0\x14\0\x43\0\x61\0\x64\0T\0o\0o\0l\0\x42\0\x61\0r\x3\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\x1\0\0\0\x1c\0W\0i\0\x64\0g\0\x65\0t\0s\0T\0o\0o\0l\0\x42\0\x61\0r\x3\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x2\0\0\0\x17\0\0\0\x18\0R\0\x65\0s\0\x65\0t\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0\x46\0i\0l\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\0K\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0\x45\0\x64\0i\0t\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\x1h\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0V\0i\0\x65\0w\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\x2{\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0(\0I\0s\0o\0m\0\x65\0t\0r\0i\0\x63\0V\0i\0\x65\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0S\0\x65\0l\0\x65\0\x63\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0\x44\0r\0\x61\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x14\0\x41\0r\0\x63\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0\x43\0i\0r\0\x63\0l\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0\x44\0i\0m\0\x65\0n\0s\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1c\0\x45\0l\0l\0i\0p\0s\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0H\0\x61\0t\0\x63\0h\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0L\0i\0n\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0P\0o\0i\0n\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1e\0P\0o\0l\0y\0l\0i\0n\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0S\0h\0\x61\0p\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0S\0p\0l\0i\0n\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0M\0o\0\x64\0i\0\x66\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0S\0n\0\x61\0p\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0$\0I\0n\0\x66\0o\0r\0m\0\x61\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0L\0\x61\0y\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0\x42\0l\0o\0\x63\0k\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0W\0i\0n\0\x64\0o\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x2\0\0\0\x13\0\0\0\xe\0O\0p\0t\0i\0o\0n\0s\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x6\0P\0\x65\0n\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0M\0i\0s\0\x63\0\x42\0l\0o\0\x63\0k\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0,\0M\0i\0s\0\x63\0\x44\0\x65\0v\0\x65\0l\0o\0p\0m\0\x65\0n\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1e\0M\0i\0s\0\x63\0\x44\0r\0\x61\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0M\0i\0s\0\x63\0I\0O\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0,\0M\0i\0s\0\x63\0I\0n\0\x66\0o\0r\0m\0\x61\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\"\0M\0i\0s\0\x63\0M\0o\0\x64\0i\0\x66\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\"\0M\0i\0s\0\x63\0S\0\x65\0l\0\x65\0\x63\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0\x41\0t\0t\0r\0i\0\x62\0u\0t\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1e\0V\0i\0\x65\0w\0p\0o\0r\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0,\0\x45\0\x64\0i\0t\0Q\0u\0i\0\x63\0k\0M\0o\0\x64\0i\0\x66\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0M\0i\0s\0\x63\0L\0\x61\0y\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0*\0M\0i\0s\0\x63\0P\0r\0o\0j\0\x65\0\x63\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1c\0O\0v\0\x65\0r\0l\0\x61\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0U\0s\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\x31\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0U\0s\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\x32\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\"\0P\0r\0o\0j\0\x65\0\x63\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0H\0\x65\0l\0p\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0)"

The user can replicate the issue just by opening the Library Browser dialog.
Using 3.32.2.0 trial on Win7 32bit installation by ZIP I cannot reproduce the failure.

Regards,
CVH

Andrew,

Related to this forum topic where an export by dwg2svg fails in various ways.

The attached file in the topic has drawing unit ‘none’, the intended unit is ‘meter’.
The content of the given file is drawn extremely far form the origin (About 228 km away).
All this should not be a problem in any way.

A simple export with: dwg2svg.bat -o “_out_g_m.svg” -g -u m -f “input1.dxf” produces an export in mm (SVG limitation) but with no visible text.

We managed to get a better output with:
dwg2svg.bat -o “_out_1000mm.svg” -g -s 1000 -u mm -f “input1.dxf” We get a viewBox in meters and a scaled canvas in mm.
Values are then in meters and things are displayed 1000 times larger.

The first occurring text item in the SVG output is one in Model_Space:
Text at (148846.7038, 172548.9401); Height 0.35; Alignment Left Base

<!-- Text: 6.01 -->
<text x="0" dx="0" y="0" dy="0.35" font-family="ARIAL.TTF" font-size="0.49" line-height="1.1" fill="#000000" transform="translate(148846.7038,172548.9401) translate(0,0.35) scale(1,-1)" text-anchor="start">6.01</text>

Breaking this down:
- SVG font size = 140% (Height of capital ‘A’ vs lower case for SVG) = 0.49
- Created at 0.35 (units=m) down what is the CAD height.
- Translated 0.35 up because alignment = Base, again the CAD height.
- Translated to its position in the drawing at (148846.7038, 172548.9401).

This text is visible and positioned correctly including the tweak -s 1000 -u mm.
The font may be incorrect depending the client.
‘ARIAL.TTF’ is listed as last in QCAD (As not a system font)

All the text items from Model_Space are now visible and sized correctly.

A Block Reference for Block ‘$TITLE_BLOCK’ is inserted in Scale (0.01, 0.01) at (148862.63734451, 172549.97956209);
For a text ‘Tekening’ at (100, -50); Height 100; Alignment Left Top the exports reads:

<!-- Text: Tekening -->
<g transform="translate(148862.6373,172549.9796) scale(0.01,0.01)">
    <text x="0" dx="0" y="0" dy="100" font-family="ARIAL.TTF" font-size="1.4" line-height="1.1" fill="#000000" transform="translate(1,-0.5) scale(1,-1)" text-anchor="start">Tekening</text>
</g>

- SVG font size = 140% = 140 but scaled down by factor 100
- Created at 100 down what is the CAD height.
- Not translated up because alignment = Top.
- Translate within the Block is scaled down by factor 100.
- As group for a second time scaled down by factor 100
- As group translated to its position in the drawing at (148862.6373, 172549.9796).

Formatted following the rules seen in the Model_Space example this should read:

<!-- Text: Tekening -->
<g transform="translate(148862.6373,172549.9796) scale(0.01,0.01)">
    <text x="0" dx="0" y="0" dy="100" font-family="ARIAL.TTF" font-size="140" line-height="1.1" fill="#000000" transform="translate(100,-50) scale(1,-1)" text-anchor="start">Tekening</text>
</g>

When manually adapted for all text items in the ‘$TITLE_BLOCK’ they appear at the intended location and in correct size. See file <_out_1000mm_rev1.svg>

Revision 1 because text of the $LEGENDRCT Block is still not visible.
Most probably outside the viewbox or too small.

I attached the related files here.

Regards,
CVH

I’d like to be able to select a portion of a given DXF file,
then export and get a PDF or SVG with just that selection.

Among the use cases is multiple versions of a design on a single sheet,
but I’ll export and use just one of them in another program.

Andrew,

When for example the last used folder was ...QCAD/libraries/templates/metric
On ‘New from Template...’ the panel previews a list with templates in that folder.
⇒ Expected behavior

In the top Drop-down list called ‘Folder’ I can select ...QCAD/libraries/templates
In my case there is only one item listed.
But that doesn’t update the list in the preview panel.

Strangely enough when I now hit the ‘Up’ button the list is updated for ...QCAD/libraries
Or one up from ...QCAD/libraries/templates while the content of ...QCAD/libraries/templates/metric was still showing.

Navigation in the list panel works as expected.
Opening a different folder with the button ‘Choose Directory’ is also working as expected.

Also (starts to) works as expected with more than one item in the Drop-down list.
With starting over new there is again only one item to select.
Again failing to synchronize when selected.

Not reacting on the drop-down list ‘Folder’ with one option can be replicated in 3.27.6 Win7 32bit

Regards,
CVH

Andrew,

Observed by a user.
It is:
A) Or approximated by a Polyline with tangentially connected Arcs within some tolerance.
B) Or interpolated by a Polyline with Line segments depending a given number of segments.

Opting for B by the checkbox keeps the preference for A enabled.

In Explode.js these preferences are twice used in an OR clause:
- Explode Spline shapes
- Explode Spline shapes from TTF text
Both as polylines ‘with arc-segments’ (bulging) OR as polylines with line-segments.

It would be more appropriate to also toggle the enabled state of:

            widgets["SplineTolerance"].enabled = !state;
            widgets["SplineTolerance_Label"].enabled = !state;

And set the enabled states on init:

        widgets["SplineTolerance"].enabled = !widgets["SplinesToLineSegments"].checked;
        widgets["SplineTolerance_Label"].enabled = !widgets["SplinesToLineSegments"].checked;

The issue was a vast amount of line segments (14344) from an explosion.
The user was not aware of the OR clause.

It would also be beneficial if users would be aware that the default preference of 64 segments means: 64 Lines per Bézier Segment times (degree + 1)

The number of Bézier Segments depends on the original Spline.
- Equal to number of points when closed
- Number of Fit-Points - 1 (degree=3)
- Or number of Control-Points - degree

Regards,
CVH

Andrew,

Some habits die hard. Like drawing on a representation of a page with the intended aspect ratio, scaled for example.
Also typically ‘drawn at scale’ seen in many third party drawings.

It would be an enhancement that the indicated ‘window’ optionally has the aspect ratio of the page. Adapting deltaX or deltaY in relation with the largest indicated delta and the aspect ratio.

Also optionally accounting for paper borders or not.

And auto orientation depending on deltaX and deltaY of the indicated ‘window’.

For now (With such third party drawings) I still resort to the workaround as described here.
Page orientation as required
Viewport offset = Lower left ‘paper’ corner
Viewport scale = paper size divided by paper representation size
Simply indicating the opposite corners of the paper representation would be easier.

Regards,
CVH

Andrew,

A minute flaw (may) occurs when we rotate an RVector by zero rads around (0, 0).

rotate() is based on: The magnitude, getAngle(), cos() and sin()
getAngle() is based on: The magnitude, a dot product, divisions and acos()
getMagnitude2D() is the hypotenuse and based on sqrt()

These functions all have some degree of error.
Accumulated and reflected in the returned RVector while that should remain steady.

I then propose that the initial test also verifies isZero.

/**
 * Rotates this vector around 0/0 by the given angle.
 */
RVector RVector::rotate(double rotation) {
    if (!valid || rotation == 0.0) {
        return *this;
    }

    double r = getMagnitude2D();
    double a = getAngle() + rotation;

    x = cos(a) * r;
    y = sin(a) * r;

    return *this;
}

The extra cost is an OR clause and an equality test.
I suppose that this is not a major hurdle.

Comparing with NaN is always false.
As expected, rotating with an angle value NaN gives x=y=NaN.
Neither z, nor the valid flag are affected.
The resulting vector is considered to be valid.

Eventually x=y=NaN will fail somewhere else.
Returning NaN for any calculation with x and/or y.

For now ...
The workaround is to verify it yourself for all RVector rotations that occur in a script:

// For all in the nature of:
pos.rotate(angle);

// Replace code with:
if (angle !== 0.0) {
    pos.rotate(angle);
}

What is more costly because ‘angle’ can be the inline result of an equation.
That must then be store in a variable or calculated twice.

In many cases we are not able to fix it. For example:
- Rotating RVector’s forth and back is rather common in various REllipse resources.
With the major axis and major point aligned with +X that serves no use ...
... But the things do shift.

As key resource the issue is not at all limited to ellipse methods only.

Regards,
CVH

After I allow my computer to lock the screen and then after a few minutes I return and unlock it, my QCAD view is distorted, with the window the same size it was, but the contents of the window limited to 1/4 of the window, 1/2 of the X dimension and 1/2 of the Y dimension. This started happening today, since I downloaded the new version, 3.32.0. I’m viewing QCAD on the larger of 2 monitors. This monitor is a 4K monitor, 3840 x 2160. The other monitor is 1920 x 1080. Closing and reopening QCAD resolves the problem, but this has to be done each time I return to my computer, and I must make sure I’ve saved my work first.

Hi Andrew,

thanks for releasing version 3.32.0. I was happy to read in the changelog about the bugfixes.
But it seems that  FS#2624  is not completely fixed. I might be my fault because I posted two problems (that directly belong together) in one entry/task (sorry for that).

Below you will find the relevant information again. It is the same as the second part of  FS#2624  (following item 2...):

When the CamToolDialog is created and shown, the validation function needs to be called. Otherwise the user can create a new tool with empty (invalid) values.

CamToolDialog.prototype.validate.call(this);
return true;

Andrew,

In the attached file ‘ActingOnNotSnappable.dxf‘:
Both Block References are on layer 0 ... Snappable
Both red shapes are on layer 2 ......... Not snappable

Start AT, radius 15, indicate near the red circle and then a point on an arc.
Solutions to the red circle are previewed while this shape is NOT snappable.

(For the record: AT is not (yet) functional for ellipses)

Implemented as in many tools:
Typically in pickEntity it is verified that the indicated entity is snappable.
Returning nothing if not.

    if (!this.isEntitySnappable(entity)) {
        return;
    }

Here ‘this’ refers to EAction.
- Checking if the given entity is not Null and derived from REntity.
Otherwise returning false ⇒ nothing.
- Retrieving the entity layer ID, its data and document.
- With a document verifying that the layer by id is snappable.
Returning false ⇒ nothing without a document.

What follows is a double test already verified for in the AND clause above:

    if (isNull(entity)) {    // # Duplicate # isEntitySnappable(entity) would be false
        return;
    }
    else { ...

After that it gets the nearest simple shape and verifies if that is supported by the tool.
For example ArcTPR, current line 145

        shape = entity.getClosestSimpleShape(pos);

For a Block Reference living on a snappable layer it is not verified if the nearest simple shape also lives on a snappable layer.

I know, it gets more complicated than that ... The nearest simple shape may be a Polyline segment, a part of a Dimension, a simple shape from an explosion and so on.
These simple shapes are themselves no existent entities with the required layer to verify.
Then it is obvious that they virtually live on the same layer as the base entity.

One can test this on only the middle segment (Arc) of the Polyline.
Unless it is moved to layer 2.
Or AT to the dimension line or even the arrows, extension lines, ...

Being snappable is not always the case when shapes are part of a reference to a Block,
part of a Block Reference.
It can not be the intention that everything in a Block must share the same layer.

One could query the nearest sub entity ID with:

var subId = entity.getClosestSubEntityId(pos, Number.NaN, true);

But that is like doing things twice because it calls the same resource of REntityData.

REntity.getClosestSimpleShape(pos) calls REntity.getClosestShape(pos, range=NaN, ignoreComplex=true)
What calls REntityData.getClosestShape(pos, range=NaN, ignoreComplex=true, subEntityId=NULL);
Returning at least an invalid RShape.

Convenience function for scripts:
REntity.getClosestSubEntityId(pos, range=NaN, ignoreComplex=true) calls REntityData.getClosestSubEntityId(pos, range=NaN, ignoreComplex=true)
What calls REntityData.getClosestShape(pos, range=NaN, ignoreComplex=true, subEntityId=RObject.INVALID_ID);
Disregarding the shape but returning the subEntityId

Combining and querying the shape, and the entity ID at once fails so far ...
... QCAD Crashes.

Regards,
CVH

I just discovered the global width parameter for polylines, which is very useful as I have often wished I could draw lines wider than 2mm. Unfortunately it seems that the global width parameter is lost when I trim the line.

I have attached a quick example file. Simply trim the extra-wide vertical line to the horizontal one and its global width parameter disappears.

Selected font size not reported correctly on rulers (too big).
Issued started to show after updating to version 3.31.2 running on a Windows 11 machine.
See attached screengrab for clarity.

Thanks!

Andrew,

Win7, latest stable QCAD trial release installed from ZIP file.
Version: 3.31.2.0 (3.31.2)
Build Date: Oct 27 2024
Revision: bae1b88
Qt Version: 5.13.2
Architecture: i386
Compiler: MSVC++ 14.16 (2017)

Fresh restart of QCAD loading an existing file.
→ Mouse wheel = Zoom IN/OUT

Switch to Print Preview mode (Ctrl+Shift+P)
→ Actuating the mouse wheel sets the origin at the left lower corner of the GUI view area.
→ No zooming occurs at all.
→ I can zoom and pan with other methods but actuating the mouse wheel in Pan Zoom mode exhibits the same issue.

Switch back to Model view (Close Print Preview)
→ Issues remain.

I can replicate the same behavior when starting QCAD and selecting a Layout with Viewport from the Block List. Essentially automatically in Print Preview mode.

What seems to be fixed in the mean time (3.27.6) is that the mouse wheel = vertical scrolling after visiting the Application Preferences. Or in and after Print Preview mode.

I would upgrade to the newest release for production when I could turn off the “Show” buttons. The Always show all properties preference of the Property Editor has no influence on that. See: Related topic

Regards,
CVH

Andrew,

It simplifies drawing circles where the target circle must be internally tangent instead of only externally. Or relevant constructions with Arcs.

It also avoids the repeated sequence:

Step 1: LI
Base point
Target point perpendicular on circle/arc, Auto Snap or forced by SU 
(or center snap SC of if that is easier)
QQ

Step 2: RM
Drawn auxiliary line of first step
Far side of circle/arc
QQ

Step 3: Use the intersection for another task, Auto Snap or forced by SI/SY 

Regards,
CVH

Andrew,

Related to this Forum topic
(ArcTPR.js: Offsets to an ellipse are fit-point splines)

The array of intersections of a fit-point spline and a circle is always empty.

The method is broken ...
OR
The method is not implemented at all without mentioning it ...!?
(Already failing with QCAD 3.27.6.0)

Workaround 1:
Quote: If we trim or cut up a fit-Point spline the result(s) is/are (a) control-point spline(s).
If any, the intersections between these splines and a circle are valid.
Downside:
If the circle crosses the cutting point (or the start=end point when closed) then
two identical intersections are included.

Workaround 2: Approximate the fit-point spline with a polyline (Explode).
Expected are approximate intersections.
Unaware if that is the method used for intersections internally.

Below a simple script that can be run with XC:
→ No intersections as fit-point spline
→ 4 intersections as control-Point spline segments (Workaround 1)

// Example points to fit:
var fitpoints = [new RVector(0, 9),
                new RVector(7, 0),
                new RVector(0, -9),
                new RVector(-7, 0)];

// Create a spline shape:
var spline = new RSpline();
spline.setFitPoints(fitpoints);
spline.setPeriodic(true);
// Create a circle shape:
var circle = new RCircle(RVector.nullVector, 8.0);

// Get intersections of spline and circle, expecting 4:
var ips1 = spline.getIntersectionPoints(circle, false);
// Report the number of intersections on the Command History:
EAction.handleUserInfo("As fit-point spline: %1 intersections (of 4)".arg(ips1.length));

// Cut up the spline in two parts -> Control-Point spline
var cutPoint = spline.getTMin() + (spline.getTDelta()/2.0);    // fitPoint (0, -9)
var splines = spline.splitAtParams([cutPoint]);

// Get intersections of both spline segments and circle:
var ips2 = splines[0].getIntersectionPoints(circle, false);
ips2 = ips2.concat(splines[1].getIntersectionPoints(circle, false));
// Report the number of intersections on the Command History:
EAction.handleUserInfo("As control-point splines: %1 intersections (of 4)".arg(ips2.length));

Regards,
CVH

no task description

Andrew,

As test I added this customiso.lin file:

;;
;;  Custom QCAD linetypes for metric system
;;
*DASHEDC,Custom Dashed _ _ _ _ _ _ _ _ _ _ _ _ _ _
A, 2, -1 
*DOTTEDC,Custom Dotted . . . . . . . . . . . . . .
A, 0, -1  

All fine but they are listed as ‘DASHEDC’ and ‘DOTTEDC’.

Kinda expected that the description would be used to list them.
All seemingly according the standard types.

Where for example

*DASHED2,Dashed (.5x) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
A, 6.35, -3.175

is listed as ‘Dashed (.5x)’ and not as ‘DASHED2’

Most probably because ‘types’ are translated and mine are not in that standard list.
It would still be appropriate to use the descriptor.
Then I have the option to include that in English or in an even custom language.

Regards,
CVH

Andrew,

The mouse tips of some manual snap options (SN, PX, PY, SH) are not handled.

For SN the mouse tips and the command line tip are unaffected.
Tips for PX and PY are only handled as command line tips:
- ‘Specify point for X coordinate’.
- ‘Specify point for Y coordinate’.
Tips for SH are only handled as command line tips:
- ‘Specify first point to measure distance from’.
- ‘Second point’.

As counter example:
For SY both mouse tips and command line tips change to:
- ‘First entity’.
- ‘Second entity’.

For SN we would expect at least a guidance that we are indicating the first or the second position. That could be implemented as command line tip but adding some additional mouse tip would be welcome.
For PX and PY we could add ‘(X)’ or ‘(Y)’ to the current mouse tip.
For SH we could add ‘(Origin)’ and ‘(Direction)’ to the current mouse tip.

Regards,
CVH

Andrew,

Related topic: https://www.qcad.org/rsforum/viewtopic.php?f=32&t=10972#p45395
The user replied “I don’t have the option to “Flatten drawing to 2D”

The topic is thus misplaced in the QCAD Professional Version forum.

On checking it seems that ‘Flatten Drawing to 2D’ is a Pro only feature.
But this important feature is not listed as such on the QCAD features page

Regards,
CVH

Andrew,

The common circle of inversion in QCAD code seems to be a circle with R=10 e.g.:

var inversionCircle = new RCircle(point.position, 10);

Said to be arbitrary meaning that any well chosen circle will do.

There are a few drawbacks with a fixed radius of 10:
- For most and much larger circles outside such an inversion circle the inversion is a tiny circle shape. The aimed results are usually larger data and those are then based on minute data from the inversion shapes.
- For smaller circles inside such an inversion circle the inversion is quite a large circle shape. The aimed results are usually smaller data and those are then based on huge data from the inversion shapes.

It tend to play a role when we are working above the 10e3 range or below the 10e-3 range. At some point Apollonius.verify() based on Apollonius.shapesTouch() may remove solutions based on a difference of more than RS.PointTolerance.

Additionally an inversion circle with radius 10 may cross the center of a circle to inverse.
Resulting in a line.

My advice is to adapt the arbitrary radius relatively to the shapes involved, to something meaningful in the problem at hand.
For example based on the smallest of the radii of the circles to inverse.

I have to advice against using a larger (fixed) tolerance than RS.PointTolerance to solve certain issues.
Again, the best tolerance in any case of comparison is an adaptive one.

Regards,
CVH

Andrew:

Apollonius.getSolutionsPCC(...) calls for ShapeAlgorithms.getTangents(circle1, circle2)
What returns an array with tangent lines to the 2 circles.
- Empty when concentric (*)
- With 4 elements, the two external tangent lines and the two internal tangent lines if they exists.

Both or one endless internal tangent line(s) exists when the distance between the centers exceeds or equals the sum of the radii. Both the external exists when the smaller circle is not fully inside the larger circle, concentric disregarding the size is already excluded. When a smaller circle is internally tangent, only one endless tangent line exists.

Apollonius.getSolutionsPCC tests for an empty array but does not verify that the first external tangent exists.

In the case that it isn’t a line piece as expected:

var p1 = tangents[0].getClosestPointOnShape(circle1.getCenter(), false);

Will throw an exception ... Halting the code in debugger mode.

Reproducible in the attached file

I can not find any other use of ShapeAlgorithms.getTangents in open sources without verifying the returned tangents.

Further I detect a flaw in ShapeAlgorithms.getTangents(...)

    var dist1 = circleCenter1.getDistanceTo(circleCenter2);
    ...
    // outer tangents:
    var dist2 = circleRadius2 - circleRadius1;
    if (dist1>dist2) {
        ...

When circleRadius1 > circleRadius2 the subtraction becomes negative and the comparison is always true.

To my knowledge dist2 must be the subtraction in absolute.
OR
Circle 2 must be the larger one but that is not a condition here.

(*) Remark that with concentric or circles in each other there are still solutions possible.
And in general there are up to 4 possible solutions for Circle2TP.
That would be a next contribution for Apollonius.js I am working on.

Regards,
CVH

Andrew,

Reported by user SteveRay: https://www.qcad.org/rsforum/viewtopic.php?t=10929

I can replicate this in 3.30.0
The Distance/Angle information is only displayed when the cursor is near a snapping point.

Regards
CVH

Andrew,

Related topic: https://www.qcad.org/rsforum/viewtopic.php?f=89&t=10934

For the drawing included in the topic: Mobilhaus.dxf
Drawing units: meters
Page units: millimeters

Page areas are defined by the user in Model_Space with a lower left corner at:
(0.0,0.0) , (21.0,0.0) , (42.0,0.0) , (63.0,0.0) and (84.0,0.0)
This are drawing units and thus meters.

When we setup the printing region to print page 2:
Scale: 1:100
Offset X: 21 (mm)
Offset Y: 0 (mm)

Prints perfectly.

But 21m in scale 1:100 would be 21cm or 210mm and that is indeed the width of a page.
Other test have shown that the Viewport offset is in drawing units.
And not 21 (mm) as displayed in the Drawing Preferences .. Printing .. Page widget.

Probably not OS related.
Tested in 3.30.0 and 3.27.6 on a Win32bit

In the topic there is also a revision of the file using Layouts and Viewports.
The most applicable way to approach something like this
Then the Viewports centers are also in drawing units.

Regards,
CVH

The CAM Profile Toolpath dialog box should have a “Save As Defaults” button, or some way in a config file to set defaults. Or even if it just defaulted to the last settings entered, it would save so much time and reduce the risk of errors.

In the sense that current open file(s) is/are part of a new project and you want that/those to remain in the list.

Can be circumvented by:
- Clear recent list
- Save current open file(s)

Related topic: https://www.qcad.org/rsforum/viewtopic.php?f=8&t=10838

Regards,
CVH

The text for the settings is too small, and requires me to hold my computer very close to my face to read. It wasn’t this way a few months ago. I don’t know what changed. Maybe it’s when I got my new computer, but I don’t think so. As you can see from the screenshot, the tree pane for selecting which page of settings isn’t affected by this problem, nor is the title of the dialog. The same problem affects both the Drawing Preferences and the Application Preferences. It also affects the Property Editor and the Layer Editor, the Command entry window and the Command output window. It may affect other components, but I haven’t tried to make an exhaustive inventory.

Andrew,

If a given point p is on the major axis then REllipse::getVectorTo(p) returns one of the major points. In the code this is handled as a special case when the point is in-line (collinear) with the major axis.
This is only correct for points outside the evolute.

On the major axis is defined by getAngle().
This may fail for a magnitude equal to or less than 1e-6.
A point that close to the center should not have a single solution at zero degrees.

The correct solutions are:
- If p is equal to the center ⇒ Two vectors to the two minor points.
- On the major axis and strictly inside the evolute ⇒ Two mirrored vectors.
- On the major axis and on or outside the evolute ⇒ The nearest major point.
- On the minor axis ⇒ The nearest minor point.

An additional problem is now what to return on a duality with full ellipses.
Or for an ellipse arc where both of two results are valid.
getVectorTo() typically returns but one unique result.

For example:
RCircle::getVectorTo(p) returns an invalid vector when the point is near the center.
Then there are an unlimited number of solutions.

Further discovered that the point related to the returned vector may fail x²/a²+y²/b²=1
Although almost on the ellipse within 2.299e-10 ... f(x,y) may return 9.5310
This example would fail REllipse::contains while the border is considered as inside.

Meanwhile implemented a ‘simple method’ to find the nearest point(s) on an ellipse.
Fast converging in 3 steps, no trigs and very accurate, about 24 lines of code.
f(x,y) returns mostly 1.000 with so far:
- a minimum of 0.9999999999999997
- a maximum of 1.0000000000000007.
In other words, it is only off for the last meaningful decimal digit.

With this all methods that are based on REllipse::getVectorTo(p) can be implemented very reliable with tolerance, border flag, ... and so on.
By default the normal for a point is given with high accuracy and a tangent is that rotated.
...
..
.

Regards,
CVH

Andrew,

Related topic: https://www.qcad.org/rsforum/viewtopic.php?f=33&t=10649

Already two different users report that Landscape is printed cropped in portrait format, both Win11. The behavior change occurred recently.
Although the second user (rdtsc) reports the same behavior for latest Mabox Linux (Manjaro, Arch.)

Can not replicate that on Win7 32 bit nor on Win10 64 bit, both are no longer or not updated OS. For one, I have no orientation setting displayed in my printer dialog.

It seems not to be related to the QCAD version:
Reported for:
- Win11 QCAD Pro 3.29
- Win11 QCAD-CAM 3.27.8.0

Regards,
CVH

Andrew,

At present QCAD/CAM the tool drop-down box displays tool number and diameter between brackets.

It would be more appropriate to display if it is a mill or a drill and/or the description of such.
In a further stage of development ball-nose ... Conical ... And so on.

I have several specialized mills with the same diameter.
End-mills, roughing mills, routing mills, face mills ....

Tools 1(ø6mm) or 2(ø6mm) don’t say much if tool 1 is a side-mill and tool 2 is a high speed drill for metal.

Related forum topic:
https://www.qcad.org/rsforum/viewtopic.php?f=31&t=10722

Regards,
CVH

Reason: Same underlined keys are used for different menus

Select and Snap = S,
Dimension and Info = I,
Modify and Misc = M,

Andrew,

When we alter about any property of a Hatch entity it seems to be recreated with a newer/higher handle.
This doesn’t influence the drawing order in direct.
But already changing the drawing order of a Hatch it is recreated as a new entity.

It starts to matters in drawing order when there are multiple entities with the same drawing order and that after save/reload. Entities with the same drawing order then receive a new drawing order based on the original but sequentially increasing based on handle.

Because a Hatch is recreated with a newer/higher handle each time a property changes it will thus always end up above the others with the same order even when the original was created earlier.

This is more pronounced when copying/pasting entities from a source to a target drawing.
The original Hatch drawing order is retained but it will always be above existent entities with the same drawing order in the target drawing after save/reload.

Most other entities are probably just updated in situ.
It is unsure to me at this point if merely updating a Hatch is even possible.
And perhaps this is related to the addObject ForceNew flag what is false by default.

Regards,
CVH

I don’t actually have any use for this idea currently, but am just posting it here to document it for consideration.

Basically, it occurred to me at least a few more useful conversions between shapes besides the existing ones could be useful.

For example:

• Converting lines into axially aligned rectangles of a specified “radius” or “diameter” (with an option to delete or keep the original line geometry).
• An option for the above (lines –> rectangles) that causes the intersections between the resulting rectangles to be automatically removed, like a kind of “automatic/magic wall creation tool” based on laying down lines instead of rectangles and then converting via this tool.
• Converting circles/ellipses and rectangles back and forth between each other via their bounding volumes. It seems reasonably likely that people will sometimes want to convert circular design elements into rectangular ones and vice versa (e.g. deciding a rectangular column makes more sense than a cylindrical one and vice versa).
• Converting any arbitrary selection into a corresponding bounding circle (not rectangle, which already exists) of sufficient size to enclose all points in the selection.

Basically, QCAD already has tools for converting shapes with operations that are a natural fit for the existing geometry, but has less tools for converting to entirely different geometry, but such uses could actually still be very useful potentially!

It seems likely to be common enough as a use case to merit inclusion, rather than just using scripting.

I don’t have any pressing need for these and I know that I could script them to create them if I really wanted to.

These are relatively minor ideas. I’m just putting this out here as more ideas for making this already wonderful software even better. :)

I was having some problems getting some shapes to fill with a solid fill and was frustrated by the awkward numeric coordinate it was giving me for where the error (the disconnected shape points) were, until I fortunately noticed that a tiny pale circle appears around the point where the error is for about just 1 second.

This is a very helpful error indicator circle but is far too easy to miss.

Perhaps making it last longer (or letting the user control that) would be beneficial.

I also wonder if showing multiple such circles (when they exist, as they did in the piece I was working on) at the same time or having that as a UI option would be good.

Anyway, goodnight all!

In my current QCAD file I’m working on, I have a circular hub with a hole in it which I am also trying to place an alternating sequence of rectangular spokes of a certain relative size around.

I had 4 spokes that I had copied and rotated 45 degrees to create 8 spokes in total around the circle. I tried scaling the the non-cardinal spokes relative to the center of the circular ring, but that causes them to also move towards the center of the ring as they shrink, thereby putting them out of place as they scale.

I therefore had to activate the scale tool once per each object and set an origin (focus) point around the area where each spoke is “attached” to the ring in order to stop each from shifting inward to the circle as it scales.

It occurred to me though that there could be a simple tool or option to do this without that.

Each of my rectangles are polyline objects and thus are coherent continuous objects.

A new scaling tool could be designed such that it is based on simply clicking on each scaling origin on each object (using snapping tools if needed) and then clicking a check button (or enter) when done and then causing the scaling GUI to appear so the user can specify the desired scaling. Each scaling would then be applied to where the polylines were clicked instead of to all the objects as one.

This would be a much faster way to rescale a bunch of objects around individually varying relative scaling origins!

I've tried several times to try to see what the "surveyor's units" option of the Angular Dimensions format in the UI preferences will display as, but all it ever seems to do is cause the angle measurement to become blank. No angles are displayed whenever this mode is selected.

Indeed, I cannot figure out what the setting actually does besides causing angles to never be displayed.

Is there a way to make this setting do something meaningful or is it just broken?

I found an old forum thread from 2016 about this same issue and it sounds like the same things is still happening since then.

I'm not a surveyor so I have no actual practical use for these units that I can yet see, but I just figured I'd add an report to the bug tracker here in case any developers aren't aware that the bug still seems to exist.

Does the setting do anything besides changing the displayed units in the status bar?

Hey, this is the first of my feature suggestion submissions that isn’t tied to a corresponding suggestion thread on the QCAD forum.

Should I always create corresponding feature suggestion threads or is it ok (or better?) to just post ideas here?

Anyway though, here’s the idea:

I noticed that it is relatively easy to use things like the QCAD Split Entities and/or Paste Along Entity tool(s) to create an even set of divisions along a curve or line.

There’s also the Misc → Draw → Counter available too, for automated counting.

These together are useful for creating a “scale ruler” to be printed on a schematic for ease of reference or for use in cases where someone forgets to bring along a physical measuring device or when someone else is using that measuring device.

For example, one could print a to-scale 1 foot long ruler (or whatever other scale is relevant, e.g. 1 inch for small objects or just as a nice scale reference/legend/key) on the schematic page for convenience.

However, it would be nice if there was a convenient tool added to the Dimensions tool category that automated this entire process and was able to create arbitrary ruler-like numbered reference scales along lines (and even better if it also worked on arcs, though less important).

Even better would be if this “auto tick” or “auto ruler” tool supported multiple levels of tick scaling (e.g. 2 or 3) such as what one sees on actual rulers.

For example, an imperial ruler for a foot (I’m in the US currently) will typically having increasingly smaller tick marks added at halfway points between each of the numbered points along the ruler’s scale, which makes using it quickly much easier. For example, it’ll have a half-length tick for half an inch and then a quarter-length tick for each quarter of an inch within an inch (with the inch’s ticks being full length).

It seems like it could be relatively easy to implement that kind of nested tick marking system, which would make it super convenient and pleasant for the user of QCAD to create usable to-scale ruler-like objects wherever they desire them with hardly any effort!

I think this idea would also fit extremely well with existing tools in the Dimensions category and would be useful for many/most QCAD users!

It’s yet another good QCAD feature that could attract more people to buy upgraded copies of QCAD in the future I think!

I hope you implement it. Small conveniences still make a big difference.

Anyway, thanks a bunch again for creating this awesome program!

That’s all the suggestions I have for today.

I hope you have a wonderful weekend and upcoming week, etc!

Hello! This is perhaps the most useful and valuable of the suggestion ideas I’ve had for QCAD so far!

I think it would be extremely useful if there was an option within the QCAD preferences for making it so that the hotkeys currently bound to each tool button in the UI (if existent) are always displayed such that they are overlaid on top of each of the buttons. There are two main approaches I can think of for doing that (both intended to avoid disturbing the existing layout of the UI):

1. Display the current hotkey binding associated by drawing it (probably in a distinct color) on one of the edges or corners of each of the buttons (such as the bottom middle side, the lower left corner, or the lower right corner). Even at a small font size I think this would be very effective and useful.
2. Instead of making the overlaid hotkey display in a small font at a side or corner of each button, you could have the hotkey text be in a large font and overlaid on top of the entire button, using things such as transparency and a distinctive (never used in the other parts of the UI) color to ensure that the button icons is still readable. A broader width of the font stroke may also help if transparency is used, so that the underlying icon lines remain more readable.

Both approaches have pros and cons. I personally lean towards the former, but Husky and CVH seemed to take issue with the readability of small fonts and so I later suggested the later option too.

They seemed opposed to both (at least during the forum discussion). However, I think this UI feature could be one of the best workflow speed improvements for the average user (many/most of whom probably don’t have time to memorize the hotkeys or just don’t end up doing so) of QCAD!

The gains in efficiency and pleasantness could be enormous potentially, even despite it QCAD already being among the most pleasant and well-designed programs I’ve ever used!

It is far faster to be able to instantly read a hotkey from the UI than to have to wait for a tooltip or to look the keystrokes up in the documentation.

Memorization is the fastest of course, but as someone who finds themselves constantly spread thin over many different programs (often half a dozen or more) for long spans of time I often find it difficult to remember all of the hotkeys for each program I use. Having such hotkeys always visible is useful for users who are spread thin, as many people increasingly in the world of software.

CVH suggested that I make custom icons myself, but doing so seems far worse than simply having QCAD automatically read and then print out the corresponding hotkeys over every tool in a programmatic and properly automated way.

I seriously think this would be one of the most awesome improvement you could ever add to QCAD!

Indeed, there is no missing feature I want more than this one!

Few programs do this but the few cases I’ve seen it the feature was extremely useful for speed without having to take weeks/months/years to fully memorize hotkeys only then forget them later. This idea eliminates that problem!

It would be glorious from a usability and accessibility standpoint! Please implement it!

Hopefully Qt’s GUI system is flexible enough to draw overlaid text over the buttons like this without to much hassle. That is the main potential impediment as I see it.

Anyway though, here is the associated forum discussion where I mentioned this idea. It was the same thread as the one where I also suggested adding a way to control tooltip delays.

I noticed that every time I move my mouse from the main working canvas (schematic area) to the tool buttons on the left sidebar there is a delay before the first hover tooltip (which displays the tool names and hotkeys corresponding to each tool button) displays.

The tooltips remain fast (near instant) after that initial hover, but it it would be nice if there was an option field for controlling how long the tooltip delay is for that initial display delay.

Currently, on my Windows 10 machine, it takes about 1 full second for the tooltip to show, which may not sound like much but feels like a lot when trying to work faster.

Here is a link to the related forum discussion, which also discussed a different (and I’d say more useful/effective) idea as well.

I’m creating two separate Bugtracker submissions for that one thread though, to keep things clean.

Perhaps I should have created two separate forum thread for that to begin with.