[SOLVED] Failed moving/isolating hatches disappear=missing

Discussion forum for C++ and script developers who are using the QCAD development platform or who are looking to contribute to QCAD (translations, documentation, etc).

Moderator: andrew

Forum rules

Always indicate your operating system and QCAD version.

Attach drawing files, scripts and screenshots.

Post one question per topic.

Post Reply
CVH
Premier Member
Posts: 3417
Joined: Wed Sep 27, 2017 4:17 pm

[SOLVED] Failed moving/isolating hatches disappear=missing

Post by CVH » Fri Nov 27, 2020 2:00 pm

Andrew,

Benchmarks on optimized hatches halted ... see:
https://qcad.org/rsforum/viewtopic.php? ... 30&p=30502

Changed my focus on lagging with hatches in general:

A solution mentioned on the forum was to set them solid.
What is no real solution! Not at all for orphans!!
Although it has a major impact on speed! See my comment at:
https://www.ribbonsoft.com/bugtracker/i ... sk_id=2021
Obvious: QCAD doesn't have to render the patterns anymore. :wink:

Another (half) solution mentioned was to lock/hide the layers with them.
But in doing so, one locks/hides all entities on those layers.
Wrote a script that isolates all hatches to subLayers of the original parent layer.
The goal is to disable all hatches simply by disabling their specific layers and go from there ...

To find them all:

Code: Select all

ids = doc.queryAllEntities(false, true, RS.EntityHatch);
I was a bit afraid that those in Blocks needed more than a simple 'move' but that seems to work out so far.
I also didn't know if we could alter the layer of orphan hatch patterns without losing the pattern itself. :?
Similar as losing it when altering its Origin.
In (very) short:

Code: Select all

op = new RModifyObjectsOperation();
hatchEntity = doc.queryEntity(id);
parentLayerName = hatchEntity.getLayerName();
subLayerName = parentLayerName + " ... HatchEntities";
hatchEntity.setLayerName(subLayerName);
op.addObject(hatchEntity, false, false); 
In the file at bugtracker: https://www.ribbonsoft.com/bugtracker/i ... sk_id=2021
There are 13.220 entities selected by TA, of which 684 Block References. :shock:
There are:
- 602 hatches in Model_Space
- 797 hatches in total => 195 in Blocks
- Only 1 Orphan pattern style called '2X4' used only once
(The pattern itself is no big deal, 2 line definitions, 1x0°, 1x90°)
- On 13 different layers

I couldn't process them in one operation because some failed:
'Transaction failed. Please check for block recursions and locked or invisible layers or blocks.'
QCAD is spending more time to 'autoSave' as to 'move'. :shock:
-> Changed from 3min to 30min autoSave (Also a solution mentioned on the forum)
Managed to do them one by one ... in debugger mode ... in sets of 10 ... very tedious but it was still a trial.

The first 500 or so went fine, that needed 50 times a 'continue' in debugger mode. (3.6sec/move)
Then there was an 'Autosave', from thereon the script did only about 60 moves every 30min. (30sec/move)
File details: *.dwg = 1.92Mb ~*.dxf = ~18.5Mb (EDIT :oops: that was zipped, it is *.dwg = 3.94Mb)
But at the end the counter said 797 and all were processed.

Saved the file as a revision.
In the report I see that 13 individual hatches didn't move ... 'Transaction failed....
2 on Model_Space and 11 in various other Blocks.
Troubled by: :shock:
- There are 6 with Block names reported not visible in the Block List
Similar as: https://qcad.org/rsforum/viewtopic.php?f=30&t=7834
On top these aren't listed on Misc .. Export Block list / List Block Attrib.

The Biggest downside: :(
In the revision:
- 600 in Model_Space => 2 lost
- 784 in total => 184 in Blocks => 11 lost
I presumed that 'failing the move' was merely NOT moving ...? :shock:

A good thing: :P
- 1 Orphan pattern with valid pattern (meaning that we can move orphan hatch patterns)

The very good thing: :!:
With the layers with hatches frozen & Locked ...
Once the zoomState includes only part (not all 13k) of the drawing QCAD works with little to no lag.

Back to the drawing board:
Enhanced the script somewhat:
- Skipping hatches already isolated
- Reports handles besides Ids
- ....

2Bcont.
When I have the 13 handles, I will report them too.

Regards,
CVH
Last edited by CVH on Wed Dec 09, 2020 8:59 am, edited 4 times in total.

CVH
Premier Member
Posts: 3417
Joined: Wed Sep 27, 2017 4:17 pm

[SOLVED] Continued: Failed moving/isolating hatches disappear=missing

Post by CVH » Mon Nov 30, 2020 6:06 am

After some more tweaking of the script ...
- Freeing up all layers upfront (Was manually: One never knows on what layers the entities from all block are defined)
- Including a ProgressBar (Although it only steps in 5% increments)
- ...
- 'Closing' the vaults (Off-Freeze-Lock)
- But still with 1 operation per hatch otherwise those that follow a transaction failure aren't moved .....

The following 13 hatches of 797 fail to move for some reason: (Brief)

id = type = handle | BlockName = id >> sublayerName

Code: Select all

41556=JIS_STN_2.5=0x42340c | *U4901=225>>M-kolon tarama ... HatchEntitiesVault
41555=JIS_STN_2.5=0x42340b | *U4901=225>>M-kolon tarama ... HatchEntitiesVault
35537=DOTS=0x388d0b | *U2130=200>>0 ... HatchEntitiesVault
35743=JIS_STN_2.5=0x389b0c | *U2132=202>>M-kolon tarama ... HatchEntitiesVault
36017=DOTS=0x39a17e | *U2136=206>>0 ... HatchEntitiesVault
35863=JIS_STN_2.5=0x399f66 | *U2135=205>>M-kolon tarama ... HatchEntitiesVault
36137=DOTS=0x39a223 | *U2137=207>>0 ... HatchEntitiesVault
22815=JIS_STN_2.5=0x34341 | *Model_Space=5>>M-kolon tarama ... HatchEntitiesVault
22824=JIS_STN_2.5=0x3469c | *Model_Space=5>>M-kolon tarama ... HatchEntitiesVault
13124=JIS_STN_2.5=0x388c3f | ghfhg=199>>M-kolon tarama ... HatchEntitiesVault
3164=JIS_STN_2.5=0x399ec0 | g jth=159>>M-kolon tarama ... HatchEntitiesVault
1712=JIS_STN_2.5=0x422c84 | A$C3E027D11=155>>M-kolon tarama ... HatchEntitiesVault
1711=JIS_STN_2.5=0x422c83 | A$C3E027D11=155>>M-kolon tarama ... HatchEntitiesVault

As an example ...
The first hatch that failed:
The script could NOT move Hatch = Object 0x42340c on layer M-kolon tarama in Block *U4901

In the saved revision of the file, among others, the Block *U4901 no longer exists.

Back in the original file:

In Model_Space:
- - - - - - - - -
TH "42340c" >> "Object selected: 41556"
Selection in Property Editor = none :!: :?:

In BlockEdit *U4901:
- - - - - - - - - - -
TH "42340c" >> "Object selected: 41556"
Selection = Hatch(1) on layer M-kolon tarama
Although there are no references visible!? :!:

ZS >> ZoomState changes to (0,-3500)-(-2000,900)

TA finds 745 entities but doesn't select any Hatch entity.

GF finds 2 hatches.
Again there are no references visible!? :!:
ZS >> ZoomState changes to (-400,-3000)-(100,1500)

With next and previous I can step between Hatch 0x42340b & Hatch 0x42340c in Block *U4901
(Hatch 0x42340b also failed to move)
For both there are no references visible!? :!:

I can step trough both their vertexes (22 & 9) and see the indicator moving.
But as mentioned higher: there are no references, nor hatches visible!? :!:

The Hatch type itself isn't problematic : JIS_STN_2.5, Origin @(-2925.19440166,16.64758959), from Entity, angle 0, scale 3

Back to the drawing board:
- including TimeStamps
- Including relevant hatching details

Some Issues I still face:
- How to tell upfront a hatch can't be moved ... :?: :?: :?:
- Can't find a way to halt AutoSave by script. (viewtopic.php?f=30&t=7847)
- Even with AutoSave off, the speed decreases the longer the scripts runs.
- Can't find a way to suspend drawing regeneration by script. (viewtopic.php?f=30&t=7848)

In the end, when fully functional, I can also include reporting to a textfile/CSV. :wink:
For now, the Command history is fine for me and is the only way to follow the progress real-time.
Indeed ... Windows ... :roll:

Regards,
CVH
Last edited by CVH on Wed Dec 09, 2020 8:59 am, edited 3 times in total.

CVH
Premier Member
Posts: 3417
Joined: Wed Sep 27, 2017 4:17 pm

[SOLVED] Continued: Failed moving/isolating hatches disappear=missing

Post by CVH » Tue Dec 01, 2020 1:47 am

The title is somewhat faulty:
The hatches don't disappear, they aren't there at all as explained in the former post.

After some more tweaking of the script ...
... but still moving the hatches one by one.
Any run up to now, there are the same 13 hatches failing to moved.

Some remarkable things come out:
Tried out to run the script while zoomed in rather deep:
Unworkable, the first 5 moves take about a half hour.
Killed the process ...

It works much better in Auto ZoomState.
- Speed:
To start, the script needs on average 3sec for every move.
After the first fault (592/797), that jumps to 20sec per move.
At 742/797 that rises to 40sec per move.
At 786/797 it drops back to 3sec per move.
Even with 2 additional faults untill all were moved.
TimingMovingHatches.png
TimingMovingHatches.png (23.34 KiB) Viewed 6389 times
- RunTime:
The script ran the last test(#7) from 08:54:51 to 10:41:04 or 1h 46m 13s in total.
It only needed 1min and some seconds beside moving hatch entities.

- The vast numbers of shapes that make up all those hatches:
The grandtotal summed to 1.187.565 shapes making up the patterns in all hatches.
Not to wonder that QCAD starts lagging rendering this vast amount of hatch segments.

The complete report:
BEYLİKDÜZÜ APARTMAN 25.10.2016.rev7.txt
(102.64 KiB) Downloaded 406 times
Regards,
CVH
Last edited by CVH on Wed Dec 09, 2020 8:59 am, edited 2 times in total.

CVH
Premier Member
Posts: 3417
Joined: Wed Sep 27, 2017 4:17 pm

[SOLVED] Continued: Failed moving/isolating hatches disappear=missing

Post by CVH » Sun Dec 06, 2020 8:52 am

Looked up everything that made sense to me ...
... but I can't find the reason why those 13 hatches can not be moved.
HatchWontMove.txt
(2.55 KiB) Downloaded 404 times

For the example investigated:
In short:
- Hatch 0x42340b & Hatch 0x42340c aren't visible in the drawing after QCAD loads it !!!
- They would exceed the local drawing frame !!! (Polyline 0x251f75)
- Both are part of Block *U4901 (0x4230f4).
- Both can be selected but only by TH.
- When selected the zoomstate will adapt with ZS to the selection !
- When selected one can Explode (XP) these in 3546 & 903 line segments !
- The explosion returns a Transaction failed error:
>>> Segments are casted but the hatch entities themselves aren't deleted !
- Exploded they look similar as Hatch 0x423049 & Hatch 0x42304a in Block *U4900 (0x422d32)
- These last two are visible inside their drawing frame. (Polyline 0x1e3a1c)
- Block 4900 & 4901 have both a non-zero Z value for their reference point.
- All 4 hatches are sitting on exactly the same Block-Layer structure.
- Exception: Block *U4901 has Custom Property : AcDbBlockRepBTag 1070:1
- This exception is also true for block *U2137 in block *U4901.
- The hatch in block *U2137 is visible and can be moved.

Most obvious is that Hatch 0x42340b & Hatch 0x42340c are NOT intended as part of the (visible) drawing.

I'll focus my quest on 'visibility' ...


2017 Related bugreport: https://www.ribbonsoft.com/bugtracker/i ... sk_id=1608
2017 Related Topic (#1010, #1011): viewtopic.php?f=33&p=18223#p18223
andrew wrote:
Wed Jun 28, 2017 4:30 pm
QCAD does not support all types of available XData (additional, typically non-standard data attached to objects).
In most cases, you can simply ignore those messages.
2020 Related Topic (#1005): viewtopic.php?f=83&t=7793&p=30358&hilit=1005#p30358
andrew wrote:
Wed Nov 18, 2020 6:03 pm
I can confirm that QCAD does not import all the XData data.
Only supported 2D entities are imported.
Your drawing may contain bodies or 3D shapes or other unsupported entities.
Last edited by CVH on Wed Dec 09, 2020 8:59 am, edited 2 times in total.

CVH
Premier Member
Posts: 3417
Joined: Wed Sep 27, 2017 4:17 pm

[SOLVED] Continued: Failed moving/isolating hatches disappear=missing

Post by CVH » Wed Dec 09, 2020 8:55 am

CVH wrote:
Fri Nov 27, 2020 2:00 pm
In the revision:
Troubled by: :shock:
- There are 6 with Block names reported not visible in the Block List
13 not moved: :(
I presumed that 'failing the move' was merely NOT moving ...? :shock:
[SOLVED]
Block names in upper case starting with an asterisk '*'
- not equal to RBlock.modelSpaceName in upper case
- not starting with '*PAPER_SPACE'
Are considerd INVALID.
See: BlockFixNames.js

The 'Quarantine hatches' script now includes a test for this and will report this at the end. :P
> Found invalid block names !
> Before saving the file use Menu .. Misc .. Block .. Fix Block Names.
- - - - -
CVH wrote:
Fri Nov 27, 2020 2:00 pm
Managed to do them one by one.
In the report I see that 13 individual hatches didn't move ... 'Transaction failed....'
I presumed that 'failing the move' was merely NOT moving ...? :shock:
[SOLVED]
This tickle down to another level of visibility, the RObject itself being set 'Invisible'.
Supported by QCAD on load and an unknown property for QCAD users BUT also cleared :!: while saving.
Solved moving with: setAllowAll(true) & setAllowInvisible(true) for the operation.

See: REntity.cpp

Code: Select all

/**
 * \return true if this entity is visible 
 * (i.e. is on current or given block, is not on a frozen or hidden layer or in a frozen block).
 */
bool REntity::isVisible(RBlock::Id blockId) const {
    const RDocument* doc = getDocument();
    if (doc==NULL) {
        return true;
    }
    if (isInvisible()) {
        // entity is invisible (part of a dynamic block and turned off):
        return false;
    }
    return doc->isEntityVisible(*this, blockId);
}
See: RTransaction.h

Code: Select all

    /**
     * True if all transactions are allowed, even transactions on locked or
     * invisible layers. Typically the case for importers.
     */
    bool allowAll;

    /**
     * True if all transactions on invisible entities are allowed,
     * typically transactions on invisible layers. Used to move entities
     * to an invisible layer.
     */
    bool allowInvisible;
    
- - - - -
CVH wrote:
Tue Dec 01, 2020 1:47 am
- RunTime:
The script ran the last test(#7) from 08:54:51 to 10:41:04 or 1h 46m 13s in total.
[SOLVED]
Moving all as one single operation, and without the failures, the runtime is about 1m 13s (or a 98,85% reduction :D ).
- less than a second for gathering information on 797 hatches and reporting 13 as invisible.
- 20 milliseconds to create 13 sublayers. (also 13 and purely a coincidence)
- 18 seconds to apply the operation and update the GUI.
- 9 seconds to move 797 hatches and reporting each individual. (EAction.handleUser.... to the command history is not so fast)
- 45 seconds to apply the operation and update the GUI.

:? Applying the operations and updating the GUI needs 86% of the total run time.
And that is about the same as merely freezing or locking one layer.

In light of the foregoing ... I'm not going to submit the script any soon. :evil:
Sorry, one can always ask for it.
No Regards,
CVH

Post Reply

Return to “QCAD Programming, Script Programming and Contributing”