More schematic page number shenanigans

I think this is a bug, but I’m not sure if it is localized on my system or not. I started this using v5.1.2-1 on Win64 (see end of message for full version spam).

I’m copying a schematic from MakeMagazine to see if I can use it in a “Learning KiCad” class that I’m developing for my maker group. I’m using hierarchical sheets (yeah, might be a mistake for an intro to KiCad class, but the schematic really lends itself to hierarchical sheets with two identical channels…). Here is what I have of the project so far (schematic only, using only standard library symbols): BoM-ElectromagneticSounds.zip (5.1 KB)

The issue I have is inconsistant display of page numbers. To repeat this, start at the top level, all Ref’d start at 100. This is as expected.

Double click on the Left Channel (top sheet) and see Page 2/3, all Ref’d start at 200. This is as expected.

Then leave the Left Channel and double click on the Right Channel (bottom sheet) and again see Page 2/3, all Ref’d start at 300. This should be Page 3/3, Ref’d are correct.

Then leave the Right Channel and double click on the Left Channel (top sheet again) and now see Page 3/3, all Ref’d still starting at 200. This should be Page 2/3 like it was a couple screenshots above.

If I print the schematic through my PDF Printer (PrimoPDF) the page numbers and Ref’d match. Printing Print Schematic.pdf (59.7 KB)

Is this oddity unique to me, to Win64, or v5.1.2-1? Thanx to everyone who helps me track this by platform before I submit a bug report.

Application: kicad
Version: (5.1.2)-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

I suggest reporting this on launchpad

Application: kicad
Version: (6.0.0-rc1-dev-1521-g81a0ab4d7), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

Switching between the hierarchical sheets via the the ‘navigating schematic hierarchy’ button it is consistent for me:

image

Left is 3/3 and Right is 2/3

But entering the subsheets via that menu also screws up page numbers.

As the dev version I’m using is rel old by now I’d say this bug has been there for a while.

1 Like

This looks like an older nightly build (current nightlies use 5.1.0 as the version prefix. Unless this has changed again recently)
So it can behave quite different to current stable and nightly builds.

Yeah, no. Same behavior as @SembazuruCDE describes.
The page numbers do not match the page, every time you enter the subsheets…
I wanted to confirm for him that this bug has been there since at least that old version :wink:

2 Likes

Done. I’ve reported this here: https://bugs.launchpad.net/kicad/+bug/1827981

Thanx for checking to make sure my computer wasn’t unique in this, @Joan_Sparky

1 Like

That was fast. Fix committed to target 5.1.3 only five hours after I reported the bug.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.