Merge pull request #14 from KubaO/staging

Add a link checking step to the build. Fix all broken links.

Author: KubaO

.github/workflows/jekyll-gh-pages.yml

@@ -43,6 +43,10 @@ jobs:
         env:
           JEKYLL_ENV: production
           PAGES_REPO_NWO: "${{ github.repository }}"
+      - name: Run HTML Proofer
+        run: bundle exec htmlproofer ./_site --disable-external --swap-urls "^${{ steps.pages.outputs.base_path }}/:/"
+        # --log-level :debug 
+        working-directory: ./docs
       - name: Upload artifact
         uses: actions/upload-pages-artifact@v3
         with:

docs/CustomControls/Defining a CustomControl.md

@@ -2,7 +2,7 @@
 title: Defining a CustomControl
 parent: CustomControls
 nav_order: 2
-permalink: /CustomControls/Defining/
+permalink: /CustomControls/Defining
 ---
 # Defining a CustomControl
 A CustomControl is simply an ordinary twinBASIC class, with a few extra attributes and requirements.
@@ -46,7 +46,7 @@ All CustomControls *must* implement CustomControls.ICustomControl.  This interfa
 ``` vb
 Sub Initialize(ByVal Context As CustomControlContext)
 ```
-    
+
 This method is called when your control is attached to a form.  You must store the provided Context object in a class field as it offers a `Repaint()` method for informing the form engine that something in your control has changed and needs to be repainted.
 
 ``` vb
@@ -59,7 +59,7 @@ This method is called when your control is detached from a form.  This allows an
 Sub Paint(ByVal Canvas As Canvas)
 ```
 
-This is the most interesting part for a CustomControl.  As such, it gets its own section, see [Painting / drawing to your control](../Painting/)
+This is the most interesting part for a CustomControl.  As such, it gets its own section, see [Painting / drawing to your control](/CustomControls/Painting)
 
 ***
 ## Minimum set of properties
@@ -78,7 +78,7 @@ Public Visible As Boolean
 
 The form designer and the form engine work with these properties, so it is important to include them in your CustomControl class.
 
-Note that the form designer works with pixel values which are not DPI-scaled.  So the Left/Top/Width/Height properties of your control do not reflect DPI scaling.  For example, if your control has a width of 50 pixels, then at DPI 150%, then the actual drawing width is 75 pixels ( see [Painting / drawing to your control](CustomControls/Painting/)).
+Note that the form designer works with pixel values which are not DPI-scaled.  So the Left/Top/Width/Height properties of your control do not reflect DPI scaling.  For example, if your control has a width of 50 pixels, then at DPI 150%, then the actual drawing width is 75 pixels ( see [Painting / drawing to your control](/CustomControls/Painting)).
 
 ***
 ## Must have a serialization constructor
@@ -88,4 +88,4 @@ CustomControls *must* offer a serialization constructor:
 Public Sub New(Serializer As SerializationInfo)
 ```
 
-The passed in Serializer object offers a `Deserialize()` method that you call in order to load the properties that have been set for your control via the form designer.  See [Property Sheet and Object Serialization](CustomControls/Properties/) for further information.
+The passed in Serializer object offers a `Deserialize()` method that you call in order to load the properties that have been set for your control via the form designer.  See [Property Sheet and Object Serialization](/CustomControls/Properties) for further information.

docs/CustomControls/Introduction.md

@@ -2,7 +2,7 @@
 title: Introduction
 parent: CustomControls
 nav_order: 1
-permalink: /CustomControls/Introduction/
+permalink: /CustomControls/Introduction
 ---
 
 ### Introduction

docs/CustomControls/Notes about the form designer.md

@@ -2,7 +2,7 @@
 title: Notes About the Form Designer
 parent: CustomControls
 nav_order: 5
-permalink: /CustomControls/Notes/
+permalink: /CustomControls/Form Designer
 ---
 
 # Notes About the Form Designer

docs/CustomControls/Painting-drawing to your control.md

@@ -2,7 +2,7 @@
 title: Painting / Drawing to Your Control
 parent: CustomControls
 nav_order: 4
-permalink: /CustomControls/Painting/
+permalink: /CustomControls/Painting
 ---
 
 # Painting / Drawing to Your Control

docs/CustomControls/Property sheet and object serialization.md

@@ -2,7 +2,7 @@
 title: Property Sheet and Object Serialization
 parent: CustomControls
 nav_order: 3
-permalink: /CustomControls/Properties/
+permalink: /CustomControls/Properties
 ---
 # Property Sheet and Object Serialization
 The form designer property sheet will pickup any **_public_** custom properties (fields) that you expose via your CustomControl class.  For example, adding a field `Public MyField As Long` will then automatically show up in the control property sheet in the form designer:

docs/CustomControls/index.md

@@ -1,7 +1,7 @@
 ---
 title: CustomControls
 nav_order: 3
-permalink: /CustomControls/
+permalink: /CustomControls
 ---
 
 # CustomControls

docs/Features/Control anchoring and docking.md

@@ -2,7 +2,7 @@
 title: Control Anchoring and Docking
 parent: Features
 nav_order: 2
-permalink: /Features/Anchoring-Docking/
+permalink: /Features/Anchoring-Docking
 ---
 
 # Anchoring

docs/Features/Overview.md

@@ -2,7 +2,7 @@
 title: Overview
 parent: Features
 nav_order: 1
-permalink: /Features/Overview/
+permalink: /Features/Overview
 ---
 
 # Overview
@@ -1191,7 +1191,7 @@ In addition to the above, forms have:
 * Control anchoring: control x/y/cx/cy can made relative, so they're automatically moved/resized with the Form. For example if you put a TextBox in the bottom right, then check the Right and Bottom anchors (in addition to Top and Left), the bottom right will size with the form on resize. This saves a lot of boiler-plate sizing code. 
 * Control docking: Controls can be fixed along one of the sides of the Form (or container), or made to fill the whole Form/container. Multiple controls can be combined and mixed/matched in docking positions.
 
-For more information on Control Anchoring and Control Docking, see the Wiki entry [Control Anchoring and Docking ‐ Automatic size and position management](../Anchoring-Docking).
+For more information on Control Anchoring and Control Docking, see the Wiki entry [Control Anchoring and Docking ‐ Automatic size and position management](Anchoring-Docking).
 
 ## Unicode support
 All tB-implemented controls support Unicode, both in the code editor and when displayed.
@@ -1213,7 +1213,7 @@ tB will eventually replace all built in controls that you're used to, for now th
 
 ### Alternatives for unimplemented controls
 
-The best option is Krool's VBCCR and VBFlexGrid projects. These are now available [from the Package Server](Packages---Importing-a-package-from-TWINSERV) in x64-compatible form, and are also DPI aware and support Visual Styles. 
+The best option is Krool's VBCCR and VBFlexGrid projects. These are now available [from the Package Server](../Packages/Importing-TWINSERV/) in x64-compatible form, and are also DPI aware and support Visual Styles. 
 
 Additionally, the original OCX controls provided by Microsoft will work fine; however, they're mostly 32-bit only. The x64 version of `MSComCtl.ocx` doesn't come with Windows and isn't legally redistributable but if you have Office 64bit, it works in tB.
 

docs/Features/Windowless vs windowed controls.md

@@ -2,7 +2,7 @@
 title: Windowless Controls vs. Windowed Controls
 parent: Features
 nav_order: 3
-permalink: /Features/Windowless/
+permalink: /Features/Windowless
 ---
 
 # Windowless Controls vs. Normal (Windowed) Controls