QCAD Bugtracker

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!

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. :)

Andrew,

When switched to French I detected a typo in the drop down box for Lineweight.

Weight 2.11mm is listed as 1.58mm {2.11m?}
https://github.com/qcad/qcad/blob/master/ts/qcadcore_fr.ts#L1228-L1229
Also see attached image file.

May I ask why only ISO types have a comma instead of a point in French.
The use of a comma is uncommon in the Property Editor even when that is the native decimal separator.
I also detect an extra space between the value and ‘mm’ and that only for the ISO types.

This only occurs in:
https://github.com/qcad/qcad/blob/master/ts/qcadcore_fr.ts https://github.com/qcad/qcad/blob/master/ts/qcadcore_pl.ts https://github.com/qcad/qcad/blob/master/ts/qcadcore_pt.ts

Probably not OS or QCAD version related.

Regards,
CVH

Andrew,

A user essentially pointed out to an ACAD textbook example.
https://qcad.org/bugtracker/index.php?do=details&task_id=2533
Step 3 of: https://autodesk.blogs.com/between_the_lines/2012/07/drawing-with-surveyors-units-in-autocad.html

Please refer to this topic:
https://www.qcad.org/rsforum/viewtopic.php?f=33&t=10652

Regards,
CVH

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

Andrew,

One Microinch is equivalent to 25.4 nanometers and I don’t consider that to be metric.

RUnit.isMetric(this.getDocument().getUnit()) returns true for RS.Microinch or value 8.

https://github.com/qcad/qcad/blob/master/src/core/RUnit.cpp#L145-L155
Returns false for: RS::Inch ; RS::Foot ; RS::Mile ; RS::Mil ; RS::Yard
... and true for all the rest.

Also see last note in: https://www.qcad.org/rsforum/viewtopic.php?f=31&t=9506&p=38295

Not to be confused with RDocument::isMetric() because that returns the measurement system unless that is RS::UnknownMeasurement what is rather impossible with drawings created by QCAD.

Regards,
CVH

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

Could you add “plain text paste” as ctrl-shift-V
Why? Because sometimes the clipboard comes in with rich text formatting that’s anti-helpful.
The workaround is to paste into a plain text editor, or the console, then recopy and repaste into qCad.

Either way the ctrl-shift-V shortcut is useful for those trained on other software but:
one could also argue that qCad should NEVER take rich text, and rather only accept the plain text with both CTRL-V and CTRL-SHIFT-V.

— CHV says

Agreed, having encountered it numerous times while documenting with text snippets from elsewhere. :roll:
Even copying Info measurements from the Command Line are Rich Text.

The best place to file a feature request is QCAD Bugtracker:
https://www.ribbonsoft.com/bugtracker/ You may need a different account there or make a new one.

May I remark that Ctrl-Shift-V is already in use for Paste along Entity (PE)
But not when the Text Editor Widget has the focus and dialog Widgets are always modal on a Win OS system. :wink:
Still, I’ll vote for it in any way.:P

Regards,
CVH

Andrew,

The _DatumFilled Block used by Datum entities (DT) is considered as not used and is purged by Purge Unused Blocks (BP).
There is no block association for these special types of arrowheads in QCAD.

After purging the Datums are not immediately updated but the special arrowheads will eventually disappear. Adding new Datums will not fix that.

Not problematic because the _DatumFilled Block is re-created on save/reload when Datum entities exists. Datums are updated.

Probably not OS or version related.
Related forum topic: https://www.qcad.org/rsforum/viewtopic.php?f=89&t=10694

Best solution would be to support different types of arrowheads and all related:
https://qcad.org/bugtracker/index.php?do=details&task_id=695 https://qcad.org/bugtracker/index.php?do=details&task_id=757 https://qcad.org/bugtracker/index.php?do=details&task_id=1157

Regards,
CVH

Reason: Same underlined keys are used for different menus

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

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

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,

I know that GCodeMM.js and GCodeIN.js are generic postprocessors.
Mostly used as base for other or custom postprocessor.

The distinct nature is pretty clear from the filename and the suffix in the display name.
Another distinct nature is that they include this.unit = RS.Millimeter / RS.Inch intended for the CAM side.

Why don’t they include at least a G20/21 in a generic header?

There are several more specific postprocessors where I miss these G-codes for the measurement system.

True, if they are not supported, no error messages would occur when omitted.
The danger is that users rely on build in postprocessors hoping that it matches with the default measurement system of their setup.

IMHO it is safer to trigger an instruction fault before attempting to execute a wrong motion.
As fail-save as possible should always be the goal.

Regards,
CVH

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 p outside the ellipse.
Or better: For points p outside the area between the focal points.

The correct solutions are:
- if p equals the center ⇒ two vectors to the two minor points.
- if p equals one of the major points ⇒ the major point itself.
- if p is in between the focal points ⇒ two vectors mirrored over the major axis.
- if p is on the unlimited axis but outside the focal points ⇒ the nearest major point.

The problem is now what to return on a duality with full ellipses.
Or for an ellipse arc where two results are valid.

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

Yesterday I set up a Windows 64 bit install of QCAD Pro which shows the same bug I have been seeing for a while in the Community linux git repo.

Create a new drawing and then go to “Print preview”. Enable “Move paper postion”, the cursor changes to the hand icon, but the paper position is unable to be moved. Only by saving the drawing, exiting the program, restarting and reopening the drawing, will the “Move paper postion” function correctly.

Affected versions tested:

Windows 64bit installer download, as of yesterday.
Linux 64bit build from git, about 20minutes ago.

For what it’s worth, this bug is not present in this previous git checkout:

Version:
3.21.1.0 (3.21.1)
Internet:
QCAD.org
Build Date:
Jul 2 2018
Revision:

Qt Version:
5.7.0
Architecture:
x86_64
Compiler:
gcc 6.3.1

Thanks for a great product.

Upon activating the Polygonal Area Tool either by clicking on the toolbar or by the IR keyboard shortcut the tool will persistently draw a polygon without clicking anything. This happens with the mouse and the trackpad on the MacBook Pro. This was happening in 3.29.3, and then after I upgraded to 3.29.4. The MacOS version is 14.1 Sonoma.

Windows
3.0.8
Application preferences > Graphics View > Appearance - Solid grid lines doesn’t change anything?

Add support for automatic text line wrapping for multiline text entities.

As it can be seen in the attached image, QCAD toolbars may dock to a position slightly outside the visible area of the screen. After having docked there, I have not been able to move them any more. Their current position is just in the middle of the screen.

The position of the toolbars remains the same after the deinstallation of QCAD, shutting down, restarting the computer and reinstalling QCAD. I kindly ask for help.

Kind regards
Reinhard