[solved] How I move and align two center
Moderator: andrew
[solved] How I move and align two center
Hello,
I would like to do something simple but I can't find how.
I would like to align the centers of two objects by moving them. I would like the snap to align centers automatically or know the most efficient way to do it. With the mouse, it's very simple for aligne two end point, but two center ...
In my example, I am in state 1 and I would like to get to state 2.
However for the example I used a free displacement which is totally imprecise. I'll need perfect alignment.
Thanks you for your help
Best regards
Example :
Info : Windows 10 with Qcad 3.25.2
I would like to do something simple but I can't find how.
I would like to align the centers of two objects by moving them. I would like the snap to align centers automatically or know the most efficient way to do it. With the mouse, it's very simple for aligne two end point, but two center ...
In my example, I am in state 1 and I would like to get to state 2.
However for the example I used a free displacement which is totally imprecise. I'll need perfect alignment.
Thanks you for your help
Best regards
Example :
Info : Windows 10 with Qcad 3.25.2
Last edited by soulearth on Mon Oct 12, 2020 2:16 pm, edited 1 time in total.
Re: How I move and align two center
Hi,
select all that belong to center B
Menu | Modify | Move/Copy (MV)
Tick Source: Select a center snap (or intersection) at B
Tick Target: Select a center snap (or intersection) at A
Choose to delete original, hit OK.
Regards,
CVH
select all that belong to center B
Menu | Modify | Move/Copy (MV)
Tick Source: Select a center snap (or intersection) at B
Tick Target: Select a center snap (or intersection) at A
Choose to delete original, hit OK.
Regards,
CVH
Re: How I move and align two center
Great, it works.
I'll save a lot of time.
thank you very much
I'll save a lot of time.
thank you very much
Re: How I move and align two center
Boring .....
How would you solve that task if the angle isn't identical? QCAD has a one tool solution for that ...
Goal:
Given:
How would you solve that task if the angle isn't identical? QCAD has a one tool solution for that ...
Goal:
Given:
Work smart, not hard: QCad Pro
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Re: How I move and align two center
Hi,
select all that belong to center B
Menu | Modify | Align Reference Points (AE)
Tick Source First reference point: Select a center snap (or intersection) at B
Tick First target point: Select a center snap (or intersection) at A
Tick Source Second reference point: Select a snap at B to align
Tick Second target point: Select a snap at A to align with
Regards,
CVH
select all that belong to center B
Menu | Modify | Align Reference Points (AE)
Tick Source First reference point: Select a center snap (or intersection) at B
Tick First target point: Select a center snap (or intersection) at A
Tick Source Second reference point: Select a snap at B to align
Tick Second target point: Select a snap at A to align with
Regards,
CVH
Re: How I move and align two center
Hi,
very nice - that works perfectly!
To keep the myth alive that many ways lead to ROM: Do you believe (like me) that QCAD offers even a second tool to solve the problem? If yes - which one and how would you efficiently operate it with all offered options?
very nice - that works perfectly!
To keep the myth alive that many ways lead to ROM: Do you believe (like me) that QCAD offers even a second tool to solve the problem? If yes - which one and how would you efficiently operate it with all offered options?
Work smart, not hard: QCad Pro
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Re: How I move and align two center
Align Reference Points is Align Reference Points available in the community version? I do not see it. This function seems very practical too ...
Re: How I move and align two center
PRO forum!
CVH
CVH
Re: How I move and align two center
it is true. sorry i'm new
Re: How I move and align two center
Ok, to answer the still unanswered question: The second QCAD tool to solve the same problem would be:
Move and Rotate (MR)
Work smart, not hard: QCad Pro
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Re: How I move and align two center
Husky,
I didn't consider MR:
- In the original example the shapes were aligned. MV
- In yours they were explicitly not and the angle difference was not a neat value. AE
- Off topic: Moving with a known, measured or calculate orientation. MR
The measurement method is tedious and there is a lot to consider for a novice to do it flawless on the first run.
When I follow your steps by the letter, the existing angle value isn't selected.
What results in 30d1 what is a syntax error.
That way you get a NaN value in the Move and Rotate Options Widget.
"30" is the initial angle value on first use and this is a persistent field displaying any former use.
"d1" is the present first parameter.
Also noticed:
When last used with a parameter and after a reboot the angle field will read d.. in red throwing a reference error.
One needs to double-click the angle field or left click hold and swipe over the "30" before the right click.
Your 'ClickPane' says 'left hold' but you don't really swipe left.
A) One has to replace the persistently stored former angle value.
Remark also that it says "Insert Measurement" not overwrite.
Inserting keeps the path open for a math expression.
Further, per-selecting a whole Options Toolbar field by default (see bug reports) is not a correct way either.
That would overwrite the whole field while it is inserting a value or a parameter.
I classified this under "Intended behavior!"
And under "One can never do good for both!"
I liked the inserting nature that was reported as a bug.
B) One has to remind to set the angle first.
When choosing the references to align first, the tools will continue with the dialog.
There we can't enter a measurement.
On top, one has to start over because the dialog has no backing up option.
Sure, we can deactivate the dialogs, in that case it will cast right away with an old value.
Remark that we have to deactivate the Move/Copy dialog for this.
The 'Rotate Dialog' preference is not related while the MR dialog takes an angular entry.
There is no singular preference option for the MR dialog.
Even using displaying 6 digits throughout.
The measured angle is reported in the command line as: "Angle: 31.38° [31.38344°]"
The tool tip of the angle fields reports "31.3834"
The Widget angle field too.
C) I find that the information is displayed truncated, what should, but not consistent with my preferences.
Now my first question will be: What angle does it actually use?
Simply "31.3834" raises a warning flag but:
D) I shouldn't have to bother about the actual angle to start with.
We are aligning things whatever the angles are.
Luckily it uses 31.3834404459263 degrees what is the delta of 202.3661577985517 & 350.9827173526254.
Eventually we get the dialog to Move or Copy or to make Multiple Copies.
Again the angle field reads "31.3834", again this is a RMathLineEdit.
E) We can't do math here because the RMathLineEdit will use the "31.3834" literally.
eg. Adding 90 degrees must be done in the angle field of the Options Toolbar.
F) AE is more accurate in aligning ...
... The longer the math road the larger the accumulated error can be.
If you don't want to do the math yourself:
Goal= 202.3661577985517 degrees.
AE: 202.36615779855154 or -6ULP's
MR: 202.36615779855126 or -16ULP's
This difference is of no issue if and only if this is the final placement of the shapes.
Every newer action induces newer kinds of math errors and they are based on these.
Don't really count on those to converge, the errors tend to run away faster and faster.
And finally.
G) AE is simply shorter:
AE: 4 clicks for a move, 5 clicks for a copy.
MR: 8 clicks and another depending on one has to swap move/copy/Multiple Copies.
Because of A-G, your question remained unanswered from my part.
I classified this under "Why easy when it can be complicated?"
But if you really think MR is more efficient, more appropriate, or even a valid equivalent ...
... then I will humbly withdraw my solution from the record.
CVH
I didn't consider MR:
- In the original example the shapes were aligned. MV
- In yours they were explicitly not and the angle difference was not a neat value. AE
- Off topic: Moving with a known, measured or calculate orientation. MR
The measurement method is tedious and there is a lot to consider for a novice to do it flawless on the first run.
When I follow your steps by the letter, the existing angle value isn't selected.
What results in 30d1 what is a syntax error.
That way you get a NaN value in the Move and Rotate Options Widget.
"30" is the initial angle value on first use and this is a persistent field displaying any former use.
"d1" is the present first parameter.
Also noticed:
When last used with a parameter and after a reboot the angle field will read d.. in red throwing a reference error.
One needs to double-click the angle field or left click hold and swipe over the "30" before the right click.
Your 'ClickPane' says 'left hold' but you don't really swipe left.
A) One has to replace the persistently stored former angle value.
Remark also that it says "Insert Measurement" not overwrite.
Inserting keeps the path open for a math expression.
Further, per-selecting a whole Options Toolbar field by default (see bug reports) is not a correct way either.
That would overwrite the whole field while it is inserting a value or a parameter.
I classified this under "Intended behavior!"
And under "One can never do good for both!"
I liked the inserting nature that was reported as a bug.
B) One has to remind to set the angle first.
When choosing the references to align first, the tools will continue with the dialog.
There we can't enter a measurement.
On top, one has to start over because the dialog has no backing up option.
Sure, we can deactivate the dialogs, in that case it will cast right away with an old value.
Remark that we have to deactivate the Move/Copy dialog for this.
The 'Rotate Dialog' preference is not related while the MR dialog takes an angular entry.
There is no singular preference option for the MR dialog.
Even using displaying 6 digits throughout.
The measured angle is reported in the command line as: "Angle: 31.38° [31.38344°]"
The tool tip of the angle fields reports "31.3834"
The Widget angle field too.
C) I find that the information is displayed truncated, what should, but not consistent with my preferences.
Now my first question will be: What angle does it actually use?
Simply "31.3834" raises a warning flag but:
D) I shouldn't have to bother about the actual angle to start with.
We are aligning things whatever the angles are.
Luckily it uses 31.3834404459263 degrees what is the delta of 202.3661577985517 & 350.9827173526254.
Eventually we get the dialog to Move or Copy or to make Multiple Copies.
Again the angle field reads "31.3834", again this is a RMathLineEdit.
E) We can't do math here because the RMathLineEdit will use the "31.3834" literally.
eg. Adding 90 degrees must be done in the angle field of the Options Toolbar.
F) AE is more accurate in aligning ...
... The longer the math road the larger the accumulated error can be.
If you don't want to do the math yourself:
Goal= 202.3661577985517 degrees.
AE: 202.36615779855154 or -6ULP's
MR: 202.36615779855126 or -16ULP's
This difference is of no issue if and only if this is the final placement of the shapes.
Every newer action induces newer kinds of math errors and they are based on these.
Don't really count on those to converge, the errors tend to run away faster and faster.
And finally.
G) AE is simply shorter:
AE: 4 clicks for a move, 5 clicks for a copy.
MR: 8 clicks and another depending on one has to swap move/copy/Multiple Copies.
Because of A-G, your question remained unanswered from my part.
I classified this under "Why easy when it can be complicated?"
But if you really think MR is more efficient, more appropriate, or even a valid equivalent ...
... then I will humbly withdraw my solution from the record.
CVH