diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
deleted file mode 100644
index dd84ea78..00000000
--- a/.github/ISSUE_TEMPLATE/bug_report.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-name: Bug report
-about: Create a report to help us improve
-title: ''
-labels: ''
-assignees: ''
-
----
-
-**Describe the bug**
-A clear and concise description of what the bug is.
-
-**To Reproduce**
-Steps to reproduce the behavior:
-1. Go to '...'
-2. Click on '....'
-3. Scroll down to '....'
-4. See error
-
-**Expected behavior**
-A clear and concise description of what you expected to happen.
-
-**Screenshots**
-If applicable, add screenshots to help explain your problem.
-
-**Desktop (please complete the following information):**
- - OS: [e.g. iOS]
- - Browser [e.g. chrome, safari]
- - Version [e.g. 22]
-
-**Smartphone (please complete the following information):**
- - Device: [e.g. iPhone6]
- - OS: [e.g. iOS8.1]
- - Browser [e.g. stock browser, safari]
- - Version [e.g. 22]
-
-**Additional context**
-Add any other context about the problem here.
diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml
new file mode 100644
index 00000000..321e5c1b
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.yml
@@ -0,0 +1,71 @@
+name: Bug Report
+description: Report a bug you've found
+title: "[Bug]: "
+labels: "bug"
+body:
+- type: markdown
+ attributes:
+ value: |
+ * IMPORTANT: Before creating an issue, start the discussion about a possible bug on our [Discord Server](https://discord.gg/q4d3ggrFVA)
+
+- type: dropdown
+ id: version
+ attributes:
+ label: What version of the icon editor are you using?
+ options:
+ - The one that came with LabVIEW
+ - Latest release from GitHub
+ - Built from source
+ - Does not apply to this issue
+ validations:
+ required: true
+- type: textarea
+ attributes:
+ label: Summary
+ description: A brief explanation of the bug and why it is problematic. Highlight the impact or severity if applicable.
+ placeholder: Tell us what you see!
+ validations:
+ required: true
+- type: textarea
+ attributes:
+ label: Steps to Reproduce (optional)
+ description: A clear, step-by-step description of how someone else can trigger the bug. Number the steps and keep them precise and minimal.
+ placeholder:
+ validations:
+ required: false
+- type: textarea
+ attributes:
+ label: Expected Behavior (optional)
+ description: What you anticipated would happen if the software was functioning correctly. Helps distinguish the intended result from the bug.
+ placeholder:
+ validations:
+ required: false
+- type: textarea
+ attributes:
+ label: Actual Behavior (optional)
+ description: The actual outcome you observed, including error messages or undesired results. Highlight differences between the actual and expected behavior.
+ placeholder:
+ validations:
+ required: false
+- type: textarea
+ attributes:
+ label: Screenshots / Logs / Error Messages (optional)
+ description: Attach or paste screenshots, console logs, stack traces, or relevant error messages. This can be crucial for quickly identifying patterns or anomalies.
+ placeholder:
+ validations:
+ required: false
+- type: textarea
+ attributes:
+ label: Possible Solution / Notes (optional)
+ description: If you’ve done any initial debugging or have a hypothesis about the cause, include it. Be clear that this is your best guess, not a definitive answer.
+ placeholder:
+ validations:
+ required: false
+- type: textarea
+ attributes:
+ label: Additional Context (optional)
+ description: Anything else relevant to the issue - Links to related issues, workarounds you’ve tried, changes you recently made that might have introduced the bug, etc.
+ placeholder:
+ validations:
+ required: false
+
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
new file mode 100644
index 00000000..7627859a
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -0,0 +1,21 @@
+blank_issues_enabled: false
+
+contact_links:
+ - name: ❓ Join Our Discord Server
+ url: https://discord.gg/q4d3ggrFVA
+ about: "Let us help you if you hit a roadblock!"
+
+ - name: 📖 Read the Docs
+ url: https://github.com/ni/labview-icon-editor#labview-icon-editor
+ about: "Check the documentation for common questions before opening an issue."
+
+issue_templates:
+ - name: 🐞 Bug Report
+ path: bug_report.yaml
+ description: "Report a reproducible issue."
+ labels: ["bug"]
+
+ - name: 🚀 Feature Request
+ path: feature_request.yaml
+ description: "Suggest a new feature or enhancement."
+ labels: ["enhancement"]
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
deleted file mode 100644
index bbcbbe7d..00000000
--- a/.github/ISSUE_TEMPLATE/feature_request.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-name: Feature request
-about: Suggest an idea for this project
-title: ''
-labels: ''
-assignees: ''
-
----
-
-**Is your feature request related to a problem? Please describe.**
-A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
-
-**Describe the solution you'd like**
-A clear and concise description of what you want to happen.
-
-**Describe alternatives you've considered**
-A clear and concise description of any alternative solutions or features you've considered.
-
-**Additional context**
-Add any other context or screenshots about the feature request here.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml
new file mode 100644
index 00000000..b71422ee
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.yml
@@ -0,0 +1,57 @@
+name: Feature request
+description: Tell us about a new feature
+title: "[Feature] "
+labels: "Enhancement"
+body:
+ - type: markdown
+ attributes:
+ value: |
+ **IMPORTANT:** Before creating an issue, start the discussion about a possible new feature on our [Discord Server](https://discord.gg/q4d3ggrFVA).
+
+ - type: textarea
+ attributes:
+ label: Summary / Description
+ description: A short explanation of the requested feature. Focus on what the feature is and the problem it addresses.
+ placeholder: "Provide a concise summary of the feature request."
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: Motivation / Use Case
+ description: Explain why you need this feature or how it will be used. Describe the specific scenario(s) or challenge(s) the feature would help address.
+ placeholder: "Describe the need for this feature and its impact."
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: Proposed Solution / Feature Details
+ description: Provide details on how you envision the feature working. Mention any interface elements, workflows, or technical details that might be relevant.
+ placeholder: "Explain how this feature should work."
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: Alternatives / Workarounds (optional)
+ description: Describe any other solutions or workarounds you have tried or considered, and why they were not sufficient or optimal.
+ placeholder: "List alternative approaches and why they don’t fully solve the problem."
+ validations:
+ required: false
+
+ - type: textarea
+ attributes:
+ label: Possible Implementation (optional)
+ description: If you’ve done some research or prototyping, share how the feature could be developed. Include code snippets or technical details if relevant.
+ placeholder: "Provide potential implementation details."
+ validations:
+ required: false
+
+ - type: textarea
+ attributes:
+ label: Additional Context (optional)
+ description: Anything else relevant to this feature request—links to related issues, references, screenshots, mockups, or other resources that help illustrate your idea.
+ placeholder: "Include any extra details, references, or screenshots."
+ validations:
+ required: false
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index 00000000..232a71fb
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,41 @@
+# GitHub Issue for the Pull Request
+Link to the relevant GitHub issue
+
+# GitHub Discussions Related to this Pull Request
+List any GitHub discussion links related to this PR
+
+# Checklists
+
+Completing these checklists ensures that your PR meets our build server requirements on the first attempt. If you're unable to complete any of the following checks, please submit your PR as a draft to the best of your ability. We will provide any clarification you may need after posting it.
+
+- [ ] I do not require assistance from NI to complete any of the following checks.
+- [ ] The changes in this PR are based on the appropriate NI-repo feature branch
+- [ ] I am submitting the changes in this PR to the appropriate NI-repo feature branch
+- [ ] I built a VI Package using the [Powershell build tool](https://github.com/ni/labview-icon-editor/wiki/automation#pwsh).
+- [ ] I installed the VI Package produced by the Powershell build tool and tested my change.
+- [ ] I tested my changes after [installing the VI package](https://github.com/ni/labview-icon-editor/wiki/test#localtesting).
+- [ ] NI has my contributor license agreement.
+
+# Summary of Changes
+
+Provide a concise overview of what is being added, modified, or fixed in this pull request. Make an emphasis on whas was not captured on the GitHub issue, or discussion associated with this PR.
+
+# Reason for Change
+
+Explain the problem or need addressed by this pull request, including any relevant background information.
+
+# Visual Aids
+
+Include any visual aids that would help the reviewer gain additional context.
+
+# Additional Information
+
+Include any further details that may assist the reviewer in understanding the context of this PR.
+
+# Testing
+
+This section describes the automated and manual tests performed for this bugfix/feature.
+
+## Manual Tests
+
+Describe any manual tests conducted.
diff --git a/.github/PULL_REQUEST_TEMPLATE/bug_fix.md b/.github/PULL_REQUEST_TEMPLATE/bug_fix.md
new file mode 100644
index 00000000..6674732a
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE/bug_fix.md
@@ -0,0 +1,42 @@
+# Bug Fix PR Template
+
+## Summary
+
+Provide a concise description of the bug and the fix.
+
+## Issue Link
+
+Link to the issue being addressed.
+
+## Root Cause Analysis
+
+Detail the root cause of the bug and how it was identified.
+
+## Changes
+
+Outline the changes made to fix the bug.
+
+## Impact
+
+Describe any implications this fix may have on other parts of the application.
+
+## Testing Strategy
+
+Explain how the fix has been tested to ensure the bug is resolved without introducing new issues.
+
+## Regression Risk
+
+Assess the risk of regression caused by this fix and steps taken to mitigate it.
+
+## Checklist
+
+- [ ] The fix has been locally tested
+
+- [ ] New unit tests have been added to prevent future regressions
+
+- [ ] The documentation has been updated if necessary
+
+## Additional Notes
+
+Any further information needed to understand the fix or its impact.
+
diff --git a/.github/PULL_REQUEST_TEMPLATE/documentation.md b/.github/PULL_REQUEST_TEMPLATE/documentation.md
new file mode 100644
index 00000000..5328d5f4
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE/documentation.md
@@ -0,0 +1,35 @@
+# Documentation Update PR Template
+
+## Summary
+
+Brief description of the documentation update and its purpose.
+
+## Areas Affected
+
+List the sections or pages of the documentation that are updated.
+
+## Details
+
+Provide detailed information about the changes made to the documentation.
+
+## Motivation
+
+Explain why these documentation changes are necessary.
+
+## Review Checklist
+
+- [ ] Spelling and grammar are correct
+
+- [ ] All links are working and correct
+
+- [ ] Documentation accurately reflects the current state of the project
+
+- [ ] Changes are clearly highlighted and easy to understand
+
+## Screenshots
+
+Include before and after screenshots for significant visual changes, if applicable.
+
+## Additional Notes
+
+Any other information that might be helpful for reviewers.
diff --git a/.github/PULL_REQUEST_TEMPLATE/empty_pull_request.md b/.github/PULL_REQUEST_TEMPLATE/empty_pull_request.md
new file mode 100644
index 00000000..e69de29b
diff --git a/.github/PULL_REQUEST_TEMPLATE/feature_request.md b/.github/PULL_REQUEST_TEMPLATE/feature_request.md
new file mode 100644
index 00000000..a1ee46a8
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE/feature_request.md
@@ -0,0 +1,43 @@
+# Feature Addition PR Template
+
+## Summary
+
+Briefly describe the feature being introduced.
+
+## Rationale
+
+Explain the reasoning behind this feature and its benefits to the project.
+
+## Design Documentation
+
+Link to any design documents or diagrams relevant to this feature.
+
+## Changes
+
+List the major changes made in this pull request.
+
+## Impact
+
+Discuss any potential impacts this feature may have on existing functionalities.
+
+## Testing
+
+Describe how the feature has been tested, including both automated and manual testing strategies.
+
+## Screenshots/Video
+
+Include screenshots or video demonstrating the new feature, if applicable.
+
+## Checklist
+
+- [ ] Code follows the project's coding standards
+
+- [ ] Unit tests covering the new feature have been added
+
+- [ ] All existing tests pass
+
+- [ ] The documentation has been updated to reflect the new feature
+
+## Additional Notes
+
+Any additional information or context relevant to this PR.
\ No newline at end of file
diff --git a/.github/PULL_REQUEST_TEMPLATE/infrastructure_change.md b/.github/PULL_REQUEST_TEMPLATE/infrastructure_change.md
new file mode 100644
index 00000000..0a0218b3
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE/infrastructure_change.md
@@ -0,0 +1,21 @@
+# Description
+
+Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
+
+
+## Type of change
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Changes to GitHub actions
+- [ ] Changes to Powershell scripts
+
+## Documentation changes made to
+
+- [ ] LabVIEW Wiki
+- [ ] Readme.md
+- [ ] No documentation changes were necessary
+
+# Checklist:
+
+- [ ] Built a [Baseline VI Package locally](https://github.com/ni/labview-icon-editor#baseline-VI-package) locally
+- [ ] Built the icon editor via a GitHub action
diff --git a/.github/scripts/fetch_store_org_data_conditional.py b/.github/scripts/fetch_store_org_data_conditional.py
new file mode 100644
index 00000000..fd197b64
--- /dev/null
+++ b/.github/scripts/fetch_store_org_data_conditional.py
@@ -0,0 +1,413 @@
+import requests
+import mysql.connector
+import os
+from datetime import datetime
+import sys
+
+# Environment variables
+GITHUB_TOKEN = os.getenv("GITHUB_TOKEN")
+ORG_NAME = os.getenv("ORG_NAME")
+REQUIRED_TOPIC = os.getenv("REQUIRED_TOPIC")
+MYSQL_HOST = os.getenv("MYSQL_HOST")
+MYSQL_USER = os.getenv("MYSQL_USER")
+MYSQL_PASSWORD = os.getenv("MYSQL_PASSWORD")
+MYSQL_DATABASE = os.getenv("MYSQL_DATABASE")
+DEBUG = (os.getenv("DEBUG", "true").lower() == "true")
+
+HEADERS = {
+ "Authorization": f"Bearer {GITHUB_TOKEN}",
+ "Accept": "application/vnd.github.v3.star+json"
+}
+
+def debug_print(msg):
+ if DEBUG:
+ print(f"[DEBUG] {msg}")
+
+def validate_env():
+ required_vars = {
+ "GITHUB_TOKEN": GITHUB_TOKEN,
+ "ORG_NAME": ORG_NAME,
+ "REQUIRED_TOPIC": REQUIRED_TOPIC,
+ "MYSQL_HOST": MYSQL_HOST,
+ "MYSQL_USER": MYSQL_USER,
+ "MYSQL_PASSWORD": MYSQL_PASSWORD,
+ "MYSQL_DATABASE": MYSQL_DATABASE
+ }
+ missing = [k for k,v in required_vars.items() if not v]
+ if missing:
+ print(f"Error: Missing required environment variables: {', '.join(missing)}")
+ sys.exit(1)
+
+def connect_to_mysql():
+ try:
+ conn = mysql.connector.connect(
+ host=MYSQL_HOST,
+ user=MYSQL_USER,
+ password=MYSQL_PASSWORD,
+ database=MYSQL_DATABASE
+ )
+ return conn
+ except mysql.connector.Error as err:
+ print(f"Error connecting to MySQL: {err}")
+ sys.exit(1)
+
+def create_tables(cursor):
+ cursor.execute("""
+ CREATE TABLE IF NOT EXISTS traffic_views (
+ id INT AUTO_INCREMENT PRIMARY KEY,
+ repo_owner VARCHAR(255),
+ repo_name VARCHAR(255),
+ timestamp DATETIME,
+ count INT,
+ uniques INT,
+ forked_from VARCHAR(255),
+ UNIQUE KEY (repo_owner, repo_name, timestamp)
+ )
+ """)
+ cursor.execute("""
+ CREATE TABLE IF NOT EXISTS traffic_clones (
+ id INT AUTO_INCREMENT PRIMARY KEY,
+ repo_owner VARCHAR(255),
+ repo_name VARCHAR(255),
+ timestamp DATETIME,
+ count INT,
+ uniques INT,
+ forked_from VARCHAR(255),
+ UNIQUE KEY (repo_owner, repo_name, timestamp)
+ )
+ """)
+ cursor.execute("""
+ CREATE TABLE IF NOT EXISTS stargazers (
+ id INT AUTO_INCREMENT PRIMARY KEY,
+ repo_owner VARCHAR(255),
+ repo_name VARCHAR(255),
+ user_login VARCHAR(255),
+ user_id INT,
+ node_id VARCHAR(255),
+ starred_url TEXT,
+ type VARCHAR(255),
+ site_admin BOOLEAN,
+ starred_at DATETIME,
+ forked_from VARCHAR(255),
+ organization VARCHAR(255),
+ UNIQUE KEY (repo_owner, repo_name, node_id)
+ )
+ """)
+ cursor.execute("""
+ CREATE TABLE IF NOT EXISTS pull_requests (
+ id INT AUTO_INCREMENT PRIMARY KEY,
+ repo_owner VARCHAR(255),
+ repo_name VARCHAR(255),
+ pr_number INT,
+ title TEXT,
+ state VARCHAR(50),
+ created_at DATETIME,
+ updated_at DATETIME,
+ closed_at DATETIME,
+ merged_at DATETIME,
+ user_login VARCHAR(255),
+ user_id INT,
+ html_url TEXT,
+ forked_from VARCHAR(255),
+ organization VARCHAR(255),
+ UNIQUE KEY (repo_owner, repo_name, pr_number)
+ )
+ """)
+ cursor.execute("""
+ CREATE TABLE IF NOT EXISTS contributors (
+ id INT AUTO_INCREMENT PRIMARY KEY,
+ repo_owner VARCHAR(255),
+ repo_name VARCHAR(255),
+ user_login VARCHAR(255),
+ user_id INT,
+ contributions INT,
+ forked_from VARCHAR(255),
+ timestamp DATETIME,
+ organization VARCHAR(255),
+ UNIQUE KEY (repo_owner, repo_name, user_login, contributions)
+ )
+ """)
+
+def convert_to_mysql_datetime(iso_timestamp):
+ if not iso_timestamp:
+ return None
+ try:
+ return datetime.strptime(iso_timestamp.replace("Z", ""), "%Y-%m-%dT%H:%M:%S")
+ except ValueError as e:
+ print(f"Error parsing timestamp '{iso_timestamp}': {e}")
+ return None
+
+def handle_403(response):
+ rate_limit_remaining = response.headers.get('X-RateLimit-Remaining')
+ try:
+ if rate_limit_remaining is not None and int(rate_limit_remaining) == 0:
+ print("Rate limit exceeded. Please wait for your limit to reset or use a token with higher limits.")
+ return
+ except ValueError:
+ pass
+ try:
+ data = response.json()
+ message = data.get("message", "")
+ if "access" in message.lower() or "permission" in message.lower() or "resource not accessible" in message.lower():
+ print("Permission issue encountered. Check if your token has the necessary scopes/permissions.")
+ else:
+ print(f"Error 403 encountered: {message}")
+ except ValueError:
+ print("A 403 error occurred, but the response could not be parsed. Check your token or permissions.")
+
+def fetch_data(url):
+ debug_print(f"Fetching data from: {url}")
+ try:
+ response = requests.get(url, headers=HEADERS, timeout=10)
+ except requests.RequestException as e:
+ print(f"Network error fetching data from {url}: {e}")
+ return None
+
+ debug_print(f"Response status: {response.status_code}")
+ if response.status_code == 200:
+ return response.json()
+ elif response.status_code == 403:
+ handle_403(response)
+ else:
+ print(f"Error fetching data from {url}: {response.text}")
+ return None
+
+def fetch_all_pages(url):
+ results = []
+ next_url = url
+ while next_url:
+ debug_print(f"Fetching page: {next_url}")
+ try:
+ response = requests.get(next_url, headers=HEADERS, timeout=10)
+ except requests.RequestException as e:
+ print(f"Network error on pagination fetch: {e}")
+ break
+
+ debug_print(f"Status: {response.status_code}")
+ if response.status_code == 200:
+ data = response.json()
+ if isinstance(data, list):
+ if not data:
+ break
+ results.extend(data)
+ elif isinstance(data, dict) and "items" in data:
+ results.extend(data["items"])
+ else:
+ if isinstance(data, dict) and data:
+ break
+ else:
+ break
+
+ links = response.headers.get('Link', '')
+ next_link = None
+ if links:
+ for part in links.split(','):
+ if 'rel="next"' in part:
+ next_link = part.split(';')[0].strip('<> ')
+ break
+ next_url = next_link
+ elif response.status_code == 403:
+ handle_403(response)
+ break
+ else:
+ print(f"Error fetching data (pagination) from {next_url}: {response.text}")
+ break
+ return results
+
+user_org_cache = {}
+
+def get_user_organization(user_login, cache):
+ if not user_login:
+ return None
+ if user_login in cache:
+ return cache[user_login]
+
+ orgs_url = f"https://api.github.com/users/{user_login}/orgs"
+ orgs = fetch_data(orgs_url)
+ if isinstance(orgs, list) and len(orgs) > 0:
+ user_org = orgs[0].get("login")
+ else:
+ user_org = None
+
+ cache[user_login] = user_org
+ return user_org
+
+def store_traffic_views(data, owner, repo, forked_from, cursor):
+ views = data.get("views", []) if data else []
+ for view in views:
+ timestamp = convert_to_mysql_datetime(view["timestamp"])
+ if timestamp:
+ cursor.execute("""
+ INSERT INTO traffic_views (repo_owner, repo_name, timestamp, count, uniques, forked_from)
+ VALUES (%s, %s, %s, %s, %s, %s)
+ ON DUPLICATE KEY UPDATE count=count
+ """, (owner, repo, timestamp, view["count"], view["uniques"], forked_from))
+
+def store_traffic_clones(data, owner, repo, forked_from, cursor):
+ clones = data.get("clones", []) if data else []
+ for clone in clones:
+ timestamp = convert_to_mysql_datetime(clone["timestamp"])
+ if timestamp:
+ cursor.execute("""
+ INSERT INTO traffic_clones (repo_owner, repo_name, timestamp, count, uniques, forked_from)
+ VALUES (%s, %s, %s, %s, %s, %s)
+ ON DUPLICATE KEY UPDATE count=count
+ """, (owner, repo, timestamp, clone["count"], clone["uniques"], forked_from))
+
+def store_stargazers(stargazers_data, owner, repo, forked_from, cursor):
+ if not isinstance(stargazers_data, list):
+ return
+ for s in stargazers_data:
+ starred_at = convert_to_mysql_datetime(s.get("starred_at"))
+ user = s.get("user", {})
+ user_login = user.get("login")
+ user_id = user.get("id")
+ node_id = user.get("node_id")
+ starred_url = user.get("starred_url")
+ user_type = user.get("type")
+ site_admin = user.get("site_admin", False)
+
+ organization = get_user_organization(user_login, user_org_cache)
+
+ # Update organization on duplicates too
+ cursor.execute("""
+ INSERT INTO stargazers (
+ repo_owner, repo_name, user_login, user_id, node_id, starred_url,
+ type, site_admin, starred_at, forked_from, organization
+ ) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
+ ON DUPLICATE KEY UPDATE node_id=node_id, organization=VALUES(organization)
+ """, (
+ owner, repo, user_login, user_id, node_id, starred_url,
+ user_type, site_admin, starred_at, forked_from, organization
+ ))
+
+def store_pull_requests(pr_data, owner, repo, forked_from, cursor):
+ if not isinstance(pr_data, list):
+ return
+ for pr in pr_data:
+ pr_number = pr.get("number")
+ title = pr.get("title")
+ state = pr.get("state")
+ created_at = convert_to_mysql_datetime(pr.get("created_at"))
+ updated_at = convert_to_mysql_datetime(pr.get("updated_at"))
+ closed_at = convert_to_mysql_datetime(pr.get("closed_at"))
+ merged_at = convert_to_mysql_datetime(pr.get("merged_at"))
+ user_login = pr.get("user", {}).get("login")
+ user_id = pr.get("user", {}).get("id")
+ html_url = pr.get("html_url")
+ organization = get_user_organization(user_login, user_org_cache)
+
+ cursor.execute("""
+ INSERT INTO pull_requests (
+ repo_owner, repo_name, pr_number, title, state, created_at, updated_at,
+ closed_at, merged_at, user_login, user_id, html_url, forked_from, organization
+ ) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
+ ON DUPLICATE KEY UPDATE
+ title=VALUES(title),
+ state=VALUES(state),
+ user_login=VALUES(user_login),
+ user_id=VALUES(user_id),
+ html_url=VALUES(html_url),
+ forked_from=VALUES(forked_from),
+ organization=VALUES(organization),
+ updated_at = CASE WHEN updated_at IS NULL AND VALUES(updated_at) IS NOT NULL THEN VALUES(updated_at) ELSE updated_at END,
+ closed_at = CASE WHEN closed_at IS NULL AND VALUES(closed_at) IS NOT NULL THEN VALUES(closed_at) ELSE closed_at END,
+ merged_at = CASE WHEN merged_at IS NULL AND VALUES(merged_at) IS NOT NULL THEN VALUES(merged_at) ELSE merged_at END
+ """, (
+ owner, repo, pr_number, title, state, created_at, updated_at,
+ closed_at, merged_at, user_login, user_id, html_url, forked_from, organization
+ ))
+
+def store_contributors(contrib_data, owner, repo, forked_from, cursor):
+ if not isinstance(contrib_data, list):
+ return
+ now = datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S')
+ for contrib in contrib_data:
+ user_login = contrib.get("login")
+ user_id = contrib.get("id")
+ contributions = contrib.get("contributions")
+ organization = get_user_organization(user_login, user_org_cache)
+
+ # Update organization on duplicates
+ cursor.execute("""
+ INSERT INTO contributors (repo_owner, repo_name, user_login, user_id, contributions, forked_from, timestamp, organization)
+ VALUES (%s, %s, %s, %s, %s, %s, %s, %s)
+ ON DUPLICATE KEY UPDATE user_id=user_id, organization=VALUES(organization)
+ """, (owner, repo, user_login, user_id, contributions, forked_from, now, organization))
+
+def process_repository(owner, repo, cursor, conn, forked_from=None):
+ base_url = f"https://api.github.com/repos/{owner}/{repo}"
+
+ # Traffic views
+ views_data = fetch_data(f"{base_url}/traffic/views")
+ store_traffic_views(views_data, owner, repo, forked_from, cursor)
+
+ # Traffic clones
+ clones_data = fetch_data(f"{base_url}/traffic/clones")
+ store_traffic_clones(clones_data, owner, repo, forked_from, cursor)
+
+ # Stargazers (paginated)
+ stargazers = fetch_all_pages(f"{base_url}/stargazers?per_page=100")
+ store_stargazers(stargazers, owner, repo, forked_from, cursor)
+
+ # Pull Requests (paginated)
+ pull_requests = fetch_all_pages(f"{base_url}/pulls?state=all&per_page=100")
+ store_pull_requests(pull_requests, owner, repo, forked_from, cursor)
+
+ # Contributors (paginated)
+ contributors = fetch_all_pages(f"{base_url}/contributors?per_page=100&anon=1")
+ store_contributors(contributors, owner, repo, forked_from, cursor)
+
+ # Commit after processing this repository
+ conn.commit()
+
+ # Forks (paginated)
+ forks = fetch_all_pages(f"{base_url}/forks?per_page=100")
+ if isinstance(forks, list):
+ for fork in forks:
+ fork_owner = fork["owner"]["login"]
+ fork_name = fork["name"]
+ debug_print(f"Processing forked repository: {fork_owner}/{fork_name}")
+ process_repository(fork_owner, fork_name, cursor, conn, forked_from=f"{owner}/{repo}")
+
+def has_required_topic(owner, repo, required_topic):
+ url = f"https://api.github.com/repos/{owner}/{repo}/topics"
+ response = fetch_data(url)
+ if response and "names" in response:
+ return required_topic in response["names"]
+ return False
+
+def check_token_validity():
+ resp = fetch_data("https://api.github.com/user")
+ if not resp or not resp.get("login"):
+ print("Invalid or insufficiently scoped GitHub token. Exiting.")
+ sys.exit(1)
+
+def main():
+ validate_env()
+ check_token_validity()
+
+ repos = fetch_all_pages(f"https://api.github.com/orgs/{ORG_NAME}/repos?per_page=100")
+ if not repos:
+ print(f"No repositories found for organization: {ORG_NAME}")
+ return
+
+ conn = connect_to_mysql()
+ cursor = conn.cursor()
+
+ create_tables(cursor)
+
+ for repo in repos:
+ owner = repo["owner"]["login"]
+ repo_name = repo["name"]
+ if has_required_topic(owner, repo_name, REQUIRED_TOPIC):
+ print(f"Processing repository: {owner}/{repo_name}")
+ process_repository(owner, repo_name, cursor, conn)
+
+ # Final commit
+ conn.commit()
+ cursor.close()
+ conn.close()
+
+if __name__ == "__main__":
+ main()
\ No newline at end of file
diff --git a/.github/workflows/Run unit tests and build.yml b/.github/workflows/Run unit tests and build.yml
deleted file mode 100644
index 982ce1d7..00000000
--- a/.github/workflows/Run unit tests and build.yml
+++ /dev/null
@@ -1,85 +0,0 @@
-# .github/workflows/build-and-test.yml
-
-name: Build and Test LabVIEW Project
-
-on:
- push:
- branches:
- - develop
-
-jobs:
- build-and-test:
- name: Build and Test the Icon Editor
- runs-on: [self-hosted, iconeditor]
-
- env:
- build_id: ${{ github.run_number }}
- build_revision: ${{ steps.get_revision.outputs.build_revision }}
- build_version: 1.0.${{ env.build_id }}.${{ env.build_revision }}
- RelativePath: ${{ vars.AgentWorkingFolder }}
- RelativePathScripts: ${{ vars.AgentWorkingFolder }}/pipeline/scripts
-
- steps:
- - name: Checkout code
- uses: actions/checkout@v1
-
- - name: Get Build Revision
- id: get_revision
- shell: bash
- run: |
- # Path to store the build revision counter
- COUNTER_FILE="${GITHUB_WORKSPACE}/.github/buildCounter.txt"
- echo "Counter file path: $COUNTER_FILE"
-
- # Initialize the counter file if it doesn't exist
- if [ ! -f "$COUNTER_FILE" ]; then
- echo "Counter file not found. Initializing to 1."
- echo "1" > "$COUNTER_FILE"
- fi
-
- # Read the current value
- build_revision=$(cat "$COUNTER_FILE")
- echo "Current build_revision: $build_revision"
-
- # Increment the counter
- new_build_revision=$((build_revision + 1))
- echo "New build_revision: $new_build_revision"
-
- # Save the new value back to the file
- echo "$new_build_revision" > "$COUNTER_FILE"
-
- # Set the output variable
- echo "::set-output name=build_revision::$build_revision"
-
- # For debugging
- ls -la "${GITHUB_WORKSPACE}/.github"
- cat "$COUNTER_FILE"
-
- - name: Set agent into development mode
- shell: pwsh
- working-directory: ${{ env.RelativePathScripts }}
- run: |
- .\Set_Development_Mode.ps1 -RelativePath "${{ env.RelativePath }}"
-
- - name: Test and Build the Icon Editor
- shell: pwsh
- working-directory: ${{ env.RelativePathScripts }}
- env:
- build_id: ${{ env.build_id }}
- build_revision: ${{ env.build_revision }}
- build_version: ${{ env.build_version }}
- run: |
- .\Build.ps1 -RelativePath "${{ env.RelativePath }}" -AbsolutePathScripts "${{ env.RelativePathScripts }}"
-
- - name: Restore agent from development mode
- shell: pwsh
- working-directory: ${{ env.RelativePathScripts }}
- run: |
- .\RevertDevelopmentMode.ps1 -RelativePath "${{ env.RelativePath }}"
-
- - name: Commit and Push Build Counter
- if: github.ref == 'refs/heads/main' || github.ref == 'refs/heads/develop'
- uses: stefanzweifel/git-auto-commit-action@v4
- with:
- commit_message: 'Increment build revision to ${{ env.build_revision }}'
- file_pattern: '.github/buildCounter.txt'
\ No newline at end of file
diff --git a/.github/workflows/build-vi-package.yml b/.github/workflows/build-vi-package.yml
new file mode 100644
index 00000000..6b9c8a2c
--- /dev/null
+++ b/.github/workflows/build-vi-package.yml
@@ -0,0 +1,391 @@
+name: Build VI Package
+
+on:
+ push:
+ branches:
+ - main
+ - develop
+ - feature/*
+ - release-alpha/*
+ - release-beta/*
+ - release-rc/*
+ - hotfix/*
+ pull_request:
+ branches:
+ - main
+ - develop
+ - release-alpha/*
+ - release-beta/*
+ - release-rc/*
+ - hotfix/*
+ workflow_dispatch:
+
+env:
+ DRAFT_RELEASE: true
+ USE_AUTO_NOTES: true
+ DISABLE_GPG_ON_FORKS: false
+ ATTACH_ARTIFACTS_TO_RELEASE: true
+
+jobs:
+ build-release:
+ runs-on: [self-hosted-windows-lv]
+ permissions:
+ contents: write
+ issues: read
+ pull-requests: read
+
+ steps:
+ ########################################################################
+ # A) Possibly disable GPG signing on forks
+ ########################################################################
+ - name: Possibly disable GPG signing on forks
+ if: ${{ env.DISABLE_GPG_ON_FORKS == 'true' }}
+ id: disable_signing
+ shell: pwsh
+ run: |
+ if ("${{ github.repository }}" -ne "ni/labview-icon-editor") {
+ Write-Host "Detected a fork; disabling GPG signing..."
+ $currentCommitGpgsign = git config --global commit.gpgsign
+ if (-not $currentCommitGpgsign) { $currentCommitGpgsign = "" }
+
+ $currentTagGpgsign = git config --global tag.gpgsign
+ if (-not $currentTagGpgsign) { $currentTagGpgsign = "" }
+
+ "old_commit_gpgsign=$currentCommitGpgsign" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+ "old_tag_gpgsign=$currentTagGpgsign" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+
+ git config --global commit.gpgsign false
+ git config --global tag.gpgsign false
+ }
+ else {
+ Write-Host "This is the official repo => no GPG changes."
+ "old_commit_gpgsign=" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+ "old_tag_gpgsign=" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+ }
+
+ ########################################################################
+ # 1) Check out code (full depth)
+ ########################################################################
+ - name: Check out code
+ uses: actions/checkout@v3
+ with:
+ persist-credentials: true
+ fetch-depth: 0
+
+ # This fixes the dubious ownership issue
+ - name: Trust repository folder (Git safe.directory)
+ run: git config --global --add safe.directory "$env:GITHUB_WORKSPACE"
+ shell: pwsh
+
+ ########################################################################
+ # 2) Determine bump type from labels (major/minor/patch), else none
+ ########################################################################
+ - name: Determine bump type
+ id: bump_type
+ uses: actions/github-script@v6
+ with:
+ github-token: ${{ secrets.GITHUB_TOKEN }}
+ script: |
+ if (context.event_name === 'pull_request') {
+ const labels = context.payload.pull_request.labels.map(l => l.name.toLowerCase());
+ core.info(`Found labels on PR: ${labels.join(', ')}`);
+
+ let bump = 'none';
+ if (labels.includes('major')) {
+ bump = 'major';
+ } else if (labels.includes('minor')) {
+ bump = 'minor';
+ } else if (labels.includes('patch')) {
+ bump = 'patch';
+ }
+ core.setOutput('bump_type', bump);
+ } else {
+ core.setOutput('bump_type', 'none');
+ }
+
+ ########################################################################
+ # 3) Commit-based build number
+ ########################################################################
+ - name: Determine build number
+ id: inc_build
+ shell: pwsh
+ run: |
+ git fetch --unshallow 2>$null || Write-Host "Already a full clone."
+ $commitCount = git rev-list --count HEAD
+ Write-Host "Commit-based build number => $commitCount"
+ "new_build_number=$commitCount" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+
+ ########################################################################
+ # 4) Parse latest version tag, apply major/minor/patch if found
+ ########################################################################
+ - name: Compute version string
+ id: next_version
+ shell: pwsh
+ env:
+ BUMP_TYPE: ${{ steps.bump_type.outputs.bump_type }}
+ BUILD_NUMBER: ${{ steps.inc_build.outputs.new_build_number }}
+ run: |
+ Write-Host "Bump type: $($env:BUMP_TYPE)"
+ Write-Host "Build number: $($env:BUILD_NUMBER)"
+
+ $branchRef = $env:GITHUB_REF -replace '^refs/heads/', ''
+ Write-Host "Full branchRef: $branchRef"
+
+ # Find the last stable tag (fallback to 0.0.0 if none)
+ $latestTag = git describe --tags --abbrev=0 2>$null
+ if ([string]::IsNullOrEmpty($latestTag)) {
+ $baseMajor = 0
+ $baseMinor = 0
+ $basePatch = 0
+ }
+ else {
+ $tagNoPrefix = $latestTag.TrimStart('v')
+ $versionPart = $tagNoPrefix -replace '-build.*',''
+ $baseMajor, $baseMinor, $basePatch = $versionPart.Split('.')
+ }
+
+ $newMajor = [int]$baseMajor
+ $newMinor = [int]$baseMinor
+ $newPatch = [int]$basePatch
+
+ # Apply label-based semantic bump
+ switch ($env:BUMP_TYPE) {
+ 'major' {
+ $newMajor++
+ $newMinor = 0
+ $newPatch = 0
+ }
+ 'minor' {
+ $newMinor++
+ $newPatch = 0
+ }
+ 'patch' {
+ $newPatch++
+ }
+ 'none' { }
+ }
+
+ # If alpha/beta/rc => generate pre-release suffix
+ $preSuffix = ""
+ if ($branchRef -like 'release-alpha/*') {
+ $countAlpha = git rev-list --count HEAD
+ if ([string]::IsNullOrEmpty($countAlpha)) { $countAlpha = 1 }
+ $preSuffix = "alpha.$countAlpha"
+ }
+ elseif ($branchRef -like 'release-beta/*') {
+ $countBeta = git rev-list --count HEAD
+ if ([string]::IsNullOrEmpty($countBeta)) { $countBeta = 1 }
+ $preSuffix = "beta.$countBeta"
+ }
+ elseif ($branchRef -like 'release-rc/*') {
+ $countRc = git rev-list --count HEAD
+ if ([string]::IsNullOrEmpty($countRc)) { $countRc = 1 }
+ $preSuffix = "rc.$countRc"
+ }
+
+ if ([string]::IsNullOrEmpty($preSuffix)) {
+ $version = "v$($newMajor).$($newMinor).$($newPatch)-build$($env:BUILD_NUMBER)"
+ $isPrerelease = "false"
+ }
+ else {
+ $version = "v$($newMajor).$($newMinor).$($newPatch)-$preSuffix-build$($env:BUILD_NUMBER)"
+ $isPrerelease = "true"
+ }
+
+ Write-Host "Computed version => $version"
+ "VERSION=$version" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+ "IS_PRERELEASE=$isPrerelease" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+ "MAJOR=$newMajor" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+ "MINOR=$newMinor" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+ "PATCH=$newPatch" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+
+ ########################################################################
+ # 5) Build the icon editor VI package
+ ########################################################################
+ - name: Build the icon editor VI package
+ shell: pwsh
+ env:
+ MAJOR: ${{ steps.next_version.outputs.MAJOR }}
+ MINOR: ${{ steps.next_version.outputs.MINOR }}
+ PATCH: ${{ steps.next_version.outputs.PATCH }}
+ BUILD: ${{ steps.inc_build.outputs.new_build_number }}
+ COMMIT: ${{ github.sha }}
+ run: |
+ $repoRoot = $env:GITHUB_WORKSPACE
+ $scriptsFolder = Join-Path $repoRoot 'pipeline/scripts'
+
+ # Split the 'owner/repo' string to extract org and repository
+ $org, $repo = $env:GITHUB_REPOSITORY -split '/'
+
+ Write-Host "Building VI package => MAJOR=$($env:MAJOR), MINOR=$($env:MINOR), PATCH=$($env:PATCH), BUILD=$($env:BUILD)"
+ Write-Host "CompanyName => $org"
+ Write-Host "AuthorName => $repo"
+
+ # Call the updated Build.ps1 which now expects -CompanyName and -AuthorName
+ .\pipeline\scripts\Build.ps1 `
+ -RelativePath $repoRoot `
+ -AbsolutePathScripts $scriptsFolder `
+ -Major $env:MAJOR `
+ -Minor $env:MINOR `
+ -Patch $env:PATCH `
+ -Build $env:BUILD `
+ -Commit $env:COMMIT `
+ -CompanyName $org `
+ -AuthorName $repo
+
+ ########################################################################
+ # 6) Capture the .vip file path as a step output
+ ########################################################################
+ - name: Discover .vip path
+ id: find_vip
+ shell: pwsh
+ run: |
+ $vipFile = Get-ChildItem -Path "builds/VI Package" -Filter "*.vip" -ErrorAction Stop | Select-Object -First 1
+ if (-not $vipFile) {
+ Write-Host "No .vip file found in builds/VI Package!"
+ exit 1
+ }
+ Write-Host "Discovered VIP File: $($vipFile.FullName)"
+ "vip_path=$($vipFile.FullName)" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+
+ ########################################################################
+ # 7) Upload ephemeral artifact (the .vip file)
+ ########################################################################
+ - name: Upload ephemeral artifact
+ uses: actions/upload-artifact@v4
+ with:
+ name: ${{ steps.next_version.outputs.VERSION }}
+ path: ${{ steps.find_vip.outputs.vip_path }}
+
+ ########################################################################
+ # 8) Create & push tag (skip if it's a PR)
+ ########################################################################
+ - name: Create & push tag
+ if: ${{ github.event_name != 'pull_request' }}
+ shell: pwsh
+ run: |
+ $VERSION = "${{ steps.next_version.outputs.VERSION }}"
+ git config user.name "github-actions[bot]"
+ git config user.email "github-actions[bot]@users.noreply.github.com"
+ git tag -a $VERSION -m "Auto-tag by CI for $VERSION"
+ git push origin $VERSION
+
+ ########################################################################
+ # 9) Create GitHub Release (capture release_id)
+ ########################################################################
+ - name: Create GitHub Release
+ if: ${{ success() && github.event_name != 'pull_request' }}
+ id: create_release
+ uses: actions/github-script@v6
+ with:
+ github-token: ${{ secrets.GITHUB_TOKEN }}
+ script: |
+ const versionTag = '${{ steps.next_version.outputs.VERSION }}';
+ const draftRelease = (process.env.DRAFT_RELEASE || 'true').toLowerCase() === 'true';
+ const useAutoNotes = (process.env.USE_AUTO_NOTES || 'true').toLowerCase() === 'true';
+ const isPrerelease = (('${{ steps.next_version.outputs.IS_PRERELEASE }}' || '').toLowerCase() === 'true');
+
+ const createParams = {
+ owner: context.repo.owner,
+ repo: context.repo.repo,
+ tag_name: versionTag,
+ name: versionTag,
+ draft: draftRelease,
+ prerelease: isPrerelease
+ };
+
+ if (useAutoNotes) {
+ createParams.generate_release_notes = true;
+ } else {
+ createParams.body = "Reference local release notes or embed within .vip.";
+ }
+
+ const response = await github.rest.repos.createRelease(createParams);
+ core.setOutput("upload_url", response.data.upload_url);
+ core.setOutput("release_id", response.data.id);
+
+ core.info(
+ `Created release [draft=${draftRelease}, prerelease=${isPrerelease}] => ${versionTag}`
+ );
+
+ ########################################################################
+ # 10) Attach .vip file(s) to Release using github-script
+ ########################################################################
+ - name: Attach .vip file(s) to Release
+ if: ${{ success() && env.ATTACH_ARTIFACTS_TO_RELEASE == 'true' && github.event_name != 'pull_request' }}
+ uses: actions/github-script@v6
+ with:
+ github-token: ${{ secrets.GITHUB_TOKEN }}
+ script: |
+ const fs = require('fs');
+ const path = require('path');
+
+ const releaseId = '${{ steps.create_release.outputs.release_id }}';
+ if (!releaseId) {
+ core.warning("No release_id found; skipping attach.");
+ return;
+ }
+
+ const vipDir = path.join(process.env.GITHUB_WORKSPACE, 'builds', 'VI Package');
+ let vipFiles = [];
+ try {
+ vipFiles = fs.readdirSync(vipDir).filter(f => f.toLowerCase().endsWith('.vip'));
+ } catch (err) {
+ core.warning(`Could not read directory 'builds/VI Package': ${err.message}`);
+ return;
+ }
+
+ if (!vipFiles.length) {
+ core.warning("No .vip files found to attach.");
+ return;
+ }
+
+ core.info(`Discovered .vip files: ${vipFiles.join(', ')}`);
+
+ for (const vipFile of vipFiles) {
+ const fullPath = path.join(vipDir, vipFile);
+ const fileData = fs.readFileSync(fullPath);
+
+ core.info(`Uploading '${vipFile}' to release #${releaseId}...`);
+
+ await github.rest.repos.uploadReleaseAsset({
+ owner: context.repo.owner,
+ repo: context.repo.repo,
+ release_id: parseInt(releaseId, 10),
+ name: vipFile,
+ data: fileData,
+ headers: {
+ 'content-type': 'application/octet-stream',
+ 'content-length': fileData.length
+ }
+ });
+ core.info(`Successfully attached '${vipFile}'!`);
+ }
+
+ ########################################################################
+ # B) Re-enable GPG signing if it was disabled
+ ########################################################################
+ - name: Re-enable GPG signing (if disabled)
+ if: ${{ always() && env.DISABLE_GPG_ON_FORKS == 'true' }}
+ shell: pwsh
+ run: |
+ if ("${{ github.repository }}" -ne "ni/labview-icon-editor") {
+ Write-Host "Restoring GPG signing..."
+ $oldCommitGpgsign = '${{ steps.disable_signing.outputs.old_commit_gpgsign }}'
+ $oldTagGpgsign = '${{ steps.disable_signing.outputs.old_tag_gpgsign }}'
+
+ if ($oldCommitGpgsign) {
+ git config --global commit.gpgsign $oldCommitGpgsign
+ } else {
+ git config --global --unset commit.gpgsign || Write-Host "commit.gpgsign wasn't originally set."
+ }
+
+ if ($oldTagGpgsign) {
+ git config --global tag.gpgsign $oldTagGpgsign
+ } else {
+ git config --global --unset tag.gpgsign || Write-Host "tag.gpgsign wasn't originally set."
+ }
+ }
+ else {
+ Write-Host "Official repo or DISABLE_GPG_ON_FORKS==false => no restore needed."
+ }
diff --git a/.github/workflows/development-mode-toggle.yml b/.github/workflows/development-mode-toggle.yml
new file mode 100644
index 00000000..42c1fe97
--- /dev/null
+++ b/.github/workflows/development-mode-toggle.yml
@@ -0,0 +1,121 @@
+name: "Toggle Development Mode"
+
+on:
+ # 1) Called by other workflows
+ workflow_call:
+ inputs:
+ mode:
+ description: "Enable or disable dev mode (reusable)."
+ type: string
+ required: true
+ default: "enable"
+
+ # 2) Triggered manually from the Actions tab
+ workflow_dispatch:
+ inputs:
+ mode:
+ description: "Enable or disable dev mode (manual)."
+ required: true
+ default: "enable"
+ type: choice
+ options:
+ - enable
+ - disable
+
+jobs:
+ toggle-dev-mode:
+ #
+ # -- FULLY DYNAMIC JOB NAME --
+ #
+ # If triggered by 'workflow_dispatch', read `github.event.inputs.mode`.
+ # Otherwise (workflow_call), read `inputs.mode`.
+ # Then display "Enable Dev Mode" or "Disable Dev Mode."
+ #
+ name: ${{
+ github.event_name == 'workflow_dispatch' &&
+ (github.event.inputs.mode == 'enable' && 'Enable Dev Mode' || 'Disable Dev Mode') ||
+ (inputs.mode == 'enable' && 'Enable Dev Mode' || 'Disable Dev Mode') }}
+
+ runs-on: [self-hosted-windows-lv]
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v3
+
+ - name: Log context
+ shell: pwsh
+ run: |
+ Write-Host "Actor: ${{ github.actor }}"
+ Write-Host "Reference: ${{ github.ref }}"
+ if ("${{ github.event_name }}" -eq "pull_request") {
+ Write-Host "Pull Request Number: ${{ github.event.pull_request.number }}"
+ } else {
+ Write-Host "Not triggered by a pull request."
+ }
+
+ - name: ${{
+ github.event_name == 'workflow_dispatch' &&
+ (github.event.inputs.mode == 'enable' && 'Running Set_Development_Mode.ps1' || 'Running RevertDevelopmentMode.ps1') ||
+ (inputs.mode == 'enable' && 'Running Set_Development_Mode.ps1' || 'Running RevertDevelopmentMode.ps1') }}
+ id: toggle_dev_mode
+ shell: pwsh
+ working-directory: pipeline/scripts
+ run: |
+ if ("${{ github.event_name }}" -eq "workflow_dispatch") {
+ if ('${{ github.event.inputs.mode }}' -eq 'enable') {
+ ./Set_Development_Mode.ps1 -RelativePath $env:GITHUB_WORKSPACE
+ } else {
+ ./RevertDevelopmentMode.ps1 -RelativePath $env:GITHUB_WORKSPACE
+ }
+ }
+ else {
+ if ('${{ inputs.mode }}' -eq 'enable') {
+ ./Set_Development_Mode.ps1 -RelativePath $env:GITHUB_WORKSPACE
+ } else {
+ ./RevertDevelopmentMode.ps1 -RelativePath $env:GITHUB_WORKSPACE
+ }
+ }
+ #
+ # -- SET OUTPUT (JSON) IF SUCCESS --
+ # Using multiline syntax to handle multi-line JSON safely
+ #
+ - name: Set environment_details output
+ if: ${{ success() }}
+ id: set_output
+ shell: pwsh
+ run: |
+ # Determine final mode for the JSON output
+ if ('${{ github.event_name }}' -eq 'workflow_dispatch') {
+ $mode = '${{ github.event.inputs.mode }}'
+ } else {
+ $mode = '${{ inputs.mode }}'
+ }
+
+ $actor = '${{ github.actor }}'
+ $timestamp = (Get-Date -Format o) # ISO8601 UTC
+ $osInfo = [System.Environment]::OSVersion.VersionString
+
+ if ('${{ github.event_name }}' -eq 'pull_request') {
+ $prNumber = '${{ github.event.pull_request.number }}'
+ } else {
+ $prNumber = 'N/A'
+ }
+
+ # Pretty-printed JSON (multi-line)
+ $jsonObject = [ordered]@{
+ mode = $mode
+ timestamp = $timestamp
+ actor = $actor
+ pr_number = $prNumber
+ os = $osInfo
+ } | ConvertTo-Json
+
+ Write-Host "JSON Output: $jsonObject"
+
+ # Write multiline output to GITHUB_OUTPUT:
+ echo "environment_details<> $env:GITHUB_OUTPUT
+ echo "$jsonObject" >> $env:GITHUB_OUTPUT
+ echo "EOF" >> $env:GITHUB_OUTPUT
+
+ outputs:
+ environment_details: ${{ steps.set_output.outputs.environment_details }}
diff --git a/.github/workflows/fetch-and-store-github-data.yml b/.github/workflows/fetch-and-store-github-data.yml
new file mode 100644
index 00000000..0c1e0d9d
--- /dev/null
+++ b/.github/workflows/fetch-and-store-github-data.yml
@@ -0,0 +1,66 @@
+name: Fetch and Store GitHub Data for Organization
+
+on:
+ schedule:
+ - cron: "0 0 * * *" # Run daily at midnight UTC
+ workflow_dispatch:
+
+jobs:
+ fetch-and-store:
+ # Self-hosted Windows runner
+ runs-on: self-hosted
+
+ # Prevent overlapping runs (optional)
+ concurrency:
+ group: fetch-and-store
+ cancel-in-progress: true
+
+ steps:
+ # 1. Checkout the repository
+ - name: Checkout Code
+ uses: actions/checkout@v3
+
+ # 2. Set up Python (pin to a minor version, e.g., "3.9" or "3.9.16")
+ - name: Set up Python
+ uses: actions/setup-python@v4
+ with:
+ python-version: '3.9'
+
+ # 3. Cache Python dependencies
+ - name: Cache dependencies
+ uses: actions/cache@v3
+ with:
+ path: ~/.cache/pip
+ key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
+ restore-keys: |
+ ${{ runner.os }}-pip-
+
+ # 4. Install Python Dependencies
+ - name: Install Python Dependencies
+ run: |
+ python -m pip install --upgrade pip
+ pip install -r requirements.txt
+
+ # 5. Run the Python script to fetch and store data
+ - name: Fetch and Store Data in MySQL
+ # Use PowerShell if your self-hosted runner requires it.
+ # For a Windows runner with PowerShell Core, you could do `shell: pwsh`
+ shell: pwsh
+ env:
+ # Secrets remain at the step level
+ GITHUB_TOKEN: ${{ secrets.PAT_GITHUB }}
+ MYSQL_PASSWORD: ${{ secrets.MYSQL_PASSWORD }}
+
+ # Other environment variables
+ ORG_NAME: "ni"
+ REQUIRED_TOPIC: "ni-open-source"
+ MYSQL_HOST: "127.0.0.1"
+ MYSQL_USER: "root"
+ MYSQL_DATABASE: "ni_open_source_github_data"
+
+ run: |
+ # Optional: any pre-check or logging in PowerShell
+ # e.g., Write-Host "Starting fetch-and-store process..."
+
+ # Run the Python script
+ python .github/scripts/fetch_store_org_data_conditional.py
diff --git a/.github/workflows/run-unit-tests.yml b/.github/workflows/run-unit-tests.yml
new file mode 100644
index 00000000..668db7b0
--- /dev/null
+++ b/.github/workflows/run-unit-tests.yml
@@ -0,0 +1,89 @@
+name: Run Unit Tests
+
+on:
+ pull_request:
+ branches:
+ - main
+ - develop
+ - release/*
+ - feature/*
+ - hotfix/*
+ types:
+ - opened
+ - synchronize
+ - reopened
+ - ready_for_review
+ push:
+ branches:
+ - main
+ - develop
+ - release/*
+ - hotfix/*
+ - feature/*
+ workflow_dispatch:
+
+jobs:
+ run-labview-tests:
+ # Matrix: test multiple OS, LabVIEW versions, and bitness
+ strategy:
+ matrix:
+ os: [windows] # Logical placeholders (map them to your self-hosted runners)
+ lv-version: ["2021"]
+ bitness: ["32","64"]
+ fail-fast: false
+
+ # Map your matrix OS to specific self-hosted runner labels
+ runs-on: ${{ matrix.os == 'windows' && 'self-hosted-windows-lv' || 'self-hosted-linux-lv' }}
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Run unit tests
+ shell: pwsh
+ working-directory: pipeline/scripts
+ run: |
+ .\RunUnitTests.ps1 -MinimumSupportedLVVersion ${{ matrix.lv-version }} -SupportedBitness ${{ matrix.bitness }}
+
+ - name: Summarize test results
+ if: always() # run this even if the previous step fails
+ shell: pwsh
+ working-directory: pipeline/scripts
+ run: |
+ $reportPath = ".\UnitTestReport.xml"
+ if (!(Test-Path $reportPath)) {
+ Write-Host "No UnitTestReport.xml found; nothing to summarize."
+ exit 0
+ }
+
+ try {
+ [xml]$xmlDoc = Get-Content $reportPath -ErrorAction Stop
+ }
+ catch {
+ Write-Host "UnitTestReport.xml is invalid or malformed: $($_.Exception.Message)"
+ exit 0
+ }
+
+ $testCases = $xmlDoc.SelectNodes("//testcase")
+ if (!$testCases -or $testCases.Count -eq 0) {
+ Write-Host "No entries found in the report."
+ exit 0
+ }
+
+ # Build a Markdown table
+ $markdown = "## LabVIEW Unit Test Results`n"
+ $markdown += "| TestCaseName | ClassName | Status | Time(s) | Assertions |`n"
+ $markdown += "|---|---|---|---|---|`n"
+
+ foreach ($case in $testCases) {
+ $name = $case.GetAttribute("name")
+ $className = $case.GetAttribute("classname")
+ $status = $case.GetAttribute("status")
+ $time = $case.GetAttribute("time")
+ $assertions = $case.GetAttribute("assertions")
+
+ $markdown += "| $name | $className | $status | $time | $assertions |`n"
+ }
+
+ # Write the table into the GitHub Step Summary, so it appears in the workflow's "Summary" tab
+ Add-Content -Path $Env:GITHUB_STEP_SUMMARY -Value $markdown
diff --git a/.github/workflows/trigger-azure-pipeline.yml b/.github/workflows/trigger-azure-pipeline.yml
deleted file mode 100644
index b8be5ded..00000000
--- a/.github/workflows/trigger-azure-pipeline.yml
+++ /dev/null
@@ -1,56 +0,0 @@
-name: PR Triggered Tests
-
-on:
- pull_request_target:
- types: [opened, synchronize, reopened]
-
-jobs:
- trigger-azure-pipeline:
- runs-on: ubuntu-latest
- if: contains(github.event.pull_request.base.ref, 'develop')
- steps:
- - name: Check if authorized to run tests
- id: check
- run: |
- # Add any conditions if necessary. For now, always allow.
- echo "ok=true" >> $GITHUB_OUTPUT
-
- - name: Trigger Azure DevOps Pipeline
- if: steps.check.outputs.ok == 'true'
- run: |
- PAT="${{ secrets.AZURE_DEVOPS_PAT }}"
- ORG="sergiovelderrain"
- PROJECT="sergiovelderrain"
- PIPELINE_ID="1"
- API_VERSION="6.0-preview.1"
-
- # Ensure PAT is not empty
- if [ -z "$PAT" ]; then
- echo "AZURE_DEVOPS_PAT is not set or empty!"
- exit 1
- fi
-
- # Base64 encode credentials
- AUTH=$(echo -n ":$PAT" | base64)
-
- # Use the PR's head ref for the pipeline branch
- PR_HEAD_REF="${{ github.event.pull_request.head.ref }}"
- JSON_BODY='{
- "resources": {
- "repositories": {
- "self": {
- "refName": "refs/heads/'"${PR_HEAD_REF}"'"
- }
- }
- }
- }'
-
- echo "Triggering Azure DevOps pipeline with the following JSON:"
- echo "$JSON_BODY"
-
- # Use --http1.1 to avoid HTTP/2 related issues, remove -s for verbosity
- curl --http1.1 -v -X POST \
- -H "Authorization: Basic $AUTH" \
- -H "Content-Type: application/json" \
- -d "$JSON_BODY" \
- "https://dev.azure.com/$ORG/$PROJECT/_apis/pipelines/$PIPELINE_ID/runs?api-version=$API_VERSION"
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 7ef8bda5..9cfa81b2 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,72 +1,160 @@
-# The Open Source LabVIEW Icon Editor
+# Contributing to the LabVIEW Icon Editor
-Just recently, the LabVIEW Icon Editor has been made open source to encourage collaboration between NI and the LabVIEW Community. Every new build of LabVIEW will grab the icon editor that has been pushed into the `main` branch from this repo.
+## Table of Contents
+1. [Introduction](#introduction)
+2. [Repository Overview](#repooverview)
+3. [Contributor License Agreement](#cla)
+4. [Contributing Philosophy](#contributephilosophy)
+5. [How to Contribute](#hotocontribute)
+ - [Entry Point: Assigning Issues](#entrypoint)
+ - [Feature Branch Creation](#featurebranch)
+6. [Non-Code Contributions](#noncodecontributions)
+7. [Creating a Discussion for a New Feature](#discussionnewfeature)
+8. [Enhancements](#enhancements)
+9. [Reporting Issues](#reportingissues)
+10. [Code of Conduct](#codeofconduct)
-The direction of the LabVIEW Icon Editor and which new features are added, and which are left out, is decided by the core team, which includes NI staff and LabVIEW community volunteers (sometimes referred to as a “cathedral” style of development).
+---
-That being said, the Icon Editor is great because of the LabVIEW users who use it, share their code with the community, and discuss ways to make LabVIEW even better. Some of the most important and undervalued work in open source is from non-code contributions, and that is where we can use the most help from you.
+
+## 1. Introduction
-# Our Contributing Philosophy
+Welcome to the **open-source LabVIEW Icon Editor** project! This repo is maintained under the **MIT license**, enabling collaboration between **NI** and the **LabVIEW community** to improve the Icon Editor. Ultimately, each official **LabVIEW release** automatically pulls the Editor from our `main` branch, so **your contributions** can appear in LabVIEW updates.
-This repo is managed via [git](https://git-scm.com), with the canonical upstream repository hosted on [GitHub](https://github.com/ni/labview-icon-editor) and it follows a pull-request model for development. If you wish to contribute, you will need to create a GitHub account, fork this project, push a branch with your changes to your project, and then submit a pull request.
+---
-# How can I help?
+
+## 2. Repository Overview
-The things we need the most help for the library and its community are:
+- **Pre-Release**: Currently supports **LabVIEW 2021–2025**, with a **green default** theme. You can modify and test it at will.
+- **Steering Committee**: Consists of NI staff and select community volunteers (a “cathedral” style approach). They determine which issues or features are ready for external dev work by labeling them as **“Workflow: Open to contribution.”**
+- **Discord Server**: Join [this channel](https://discord.gg/q4d3ggrFVA) for real-time discussions about new features, bug triage, and general Q&A.
-**🐛 Bug reports:** We simply can’t catch them all. Check [existing issues](https://github.com/ni/labview-icon-editor/issues/new/choose) and discussion first, then [create a new issue](https://github.com/ni/labview-icon-editor/issues/new/choose) to tell us what’s up.
+**Key Note**: We value both **code and non-code contributions**—testing `.vip` packages, improving docs, or providing UI feedback are equally important to shipping a robust Icon Editor.
-**💬 Answering questions and provide feedback**: New features begin by creating a discussion on our [board](https://github.com/ni/labview-icon-editor/discussions/new?category=ideas), you can provide feedback to the new features that are planned to be added to the icon editor. This is an [example](https://github.com/ni/labview-icon-editor/discussions/55) of a discussion for a new feature request.
+---
-🎬 **Work on ["Good first issue"**](https://github.com/ni/labview-icon-editor/labels/good%20first%20issue) items: You can right now assign yourself action items to finish or test a feature. Check out the [issues](https://github.com/ni/labview-icon-editor/issues) section and look for any issue labeled as [Good first issue](https://github.com/ni/labview-icon-editor/labels/good%20first%20issue).
+
+## 3. Contributor License Agreement (CLA)
-**✏️ Edit our [Docs](https://labview-icon-editor.dev/docs/introduction/)**: Make changes in the [labview-icon-editor-docs repo](https://github.com/ni/labview-icon-editor-docs), or click the "edit this page” button that lives on every doc site.
+Before we can merge a Pull Request from **any** external contributor, you will need to **sign our Contributor License Agreement** (CLA). This ensures that:
-All interactions should be done with care following our [Code of Conduct](https://github.com/ni/labview-icon-editor/blob/main/CODE_OF_CONDUCT.md).
+- NI and other users of the Icon Editor have the legal right to distribute your code under the **MIT license**.
+- You retain any necessary rights to your contributions, but also formally allow them to be incorporated into LabVIEW releases.
-## Enhancements
+**How to sign the CLA**: Instructions will be provided when you open your first Pull Request. You’ll be guided through a quick, one-time CLA process.
-If you have an idea or suggestion for an enhancement to the LabVIEW Icon Editor library, please use the [New Features](https://github.com/ni/labview-icon-editor/discussions/categories/new-features) discussion section. **please make sure to start a discussion about your changes.** The direction of the LabVIEW Icon Editor and which new features are added are discussed in our Discord Server and in [this GitHub discussions section](https://github.com/ni/labview-icon-editor/discussions/categories/new-features), and in the end, they are decided by the core team.
+---
-Talking to us first via the discussions section about the enhancement you want to build will be the most likely way to get your pull request into the library (see Our Contributing Philosophy above). We would hate to see you write code you’re proud of, just to learn that we’ve already been working on the same thing, or that we feel doesn’t fit into the core library.
+
+## 4. Contributing Philosophy
-Once your idea has been selected for the next release of LabVIEW, a branch will be created that you can submit your pull request to.
+We use a **pull-request model**. The key principles:
-## Creating a discussion for a new feature
+- **MIT License**: Minimizes legal barriers for external devs.
+- **Steering Committee & BDFL**: The committee (including NI & community members) steers day-to-day decisions; major roadmap calls remain with NI.
+- **Workflow Labeling**: An issue labeled “**Workflow: Open to contribution**” indicates it’s **ready** for external devs to work on.
+- **Feature Branch**: Once assigned, you’ll use a dedicated feature branch to do your dev work.
-The first step to start an enhancement to the icon editor is to create a discussion on the [New Features](https://github.com/ni/labview-icon-editor/discussions/categories/new-features) discussion board. You must describe the problem that made you want to have this enhancement.
-### 💫 Pull Requests
+---
-When submitting a PR, please follow these guidelines to ensure clarity and ease
-of review:
-
-1. **Title**: Start with a short, descriptive title that summarizes the change.
-2. **Description**:
- - **Purpose**: Explain why you are making this change.
- - **Changes Made**: Describe what changes you made and why.
- - **Related Issues**: Reference any related issues using `#issue_number`.
- - **Testing**: Outline how you tested your changes and any specific areas of
- the code to focus on during review.
-
-Please remember to sign off your commits (e.g., by using git commit -s if you
-are using the command line client). This amends your git commit message with a
-line of the form Signed-off-by: Name Lastname .
-Please include all authors of any given commit into the commit message with a
-Signed-off-by line. This indicates that you have read and signed the Developer
-Certificate of Origin (see below) and are able to legally submit your code to
-this repository.
+
+## 5. How to Contribute
-### Reporting Issues
-
-When creating an issue, please provide a detailed description to help us
-understand the problem. Here are some tips:
-
-1. **Title**: Use a clear, concise title that summarizes the issue.
-2. **Description**:
- - **What Happened**: Describe the issue you encountered.
- - **Expected Behavior**: Explain what you expected to happen.
- - **Steps to Reproduce**: List the steps necessary to reproduce the issue.
- - **Environment**: Include relevant details about your environment (e.g.,
- operating system, LabVIEW version, etc.).
- - **Screenshots**: If applicable, add screenshots to clarify the issue.
+You can contribute by **fixing bugs**, **adding new features**, **testing** other people’s PRs, or **enhancing docs**. Below is how to get started:
+
+
+### Entry Point: Assigning Issues
+
+1. **Check Labeled Issues**: Go to [GitHub Issues](https://github.com/ni/labview-icon-editor/issues?q=is%3Aissue+label%3A%22Workflow%3A%20Open+to+contribution%22).
+2. **Comment**: If you see something you’d like to tackle, let us know in the issue thread (e.g., “I’d like to fix this—please assign me!”).
+3. **Assignment**: The Steering Committee or maintainers assign you, confirming you can begin development.
+
+> **No label, no assignment** → The issue is either under internal discussion or not yet ready for external dev.
+
+
+### Feature Branch Creation
+
+- **After You’re Assigned**: A feature branch is either generated by a GitHub Action or created by maintainers.
+- **Fork & Clone**: Typically, you’ll fork the repo, clone your fork, and then pull this feature branch locally.
+- **Implement & Test**: Use LabVIEW 2021–2025 with the green-default Icon Editor to validate your changes.
+- **Open a Pull Request**: Reference the issue in your PR. The CI pipeline builds a `.vip` package for easy testing by others.
+- **CLA Reminder**: If this is your first contribution, the CLA check will appear. Please sign it before we can merge.
+
+---
+
+
+## 6. Non-Code Contributions
+
+Non-code contributions are **crucial** to a thriving open-source project. Some ways you can help:
+
+1. **Testing**
+ - Download and install `.vip` artifacts from open pull requests.
+ - Verify the fix or feature in your LabVIEW environment and report any findings in the PR thread.
+
+2. **Documentation**
+ - Improve or expand `README.md`, `CONTRIBUTING.md`, or Wiki pages.
+ - Provide clear examples, usage steps, or troubleshooting tips for new users.
+
+3. **UI/UX Feedback**
+ - If the green-default theme or certain UI flows seem confusing, open an issue or discussion.
+ - Propose improvements to the Icon Editor’s layout or design elements.
+
+4. **Issue Triage**
+ - Help confirm if a reported bug is reproducible.
+ - Provide logs, screenshots, or more context for existing issues.
+
+5. **Community Moderation**
+ - Welcome new contributors on Discord.
+ - Encourage respectful, inclusive communication.
+
+**Remember**: Non-code contributions often lead to the biggest improvements in usability, clarity, and overall adoption.
+
+---
+
+
+## 7. Creating a Discussion for a New Feature
+
+1. **Open a Discussion**: [Start a new Discussion](https://github.com/ni/labview-icon-editor/discussions/new/choose) or bring it up on our [Discord server](https://discord.gg/q4d3ggrFVA).
+2. **Gather Feedback**: Let the Steering Committee and community weigh in.
+3. **Issue Creation**: If the idea is approved, an issue labeled `Workflow: Open to contribution` will be made.
+4. **Assignment & Branch**: Once you comment to claim it, a feature branch is created, and you can start development.
+
+---
+
+
+## 8. Enhancements
+
+If you have an **enhancement** to existing functionality, it’s best to discuss it first (on Discord or GitHub Discussions). That ensures:
+
+- No duplicate work or overlapping ideas.
+- Alignment with the Steering Committee’s roadmap.
+
+If the committee agrees, they’ll add `Workflow: Open to contribution` to an issue. After you’re assigned, begin coding on the assigned feature branch.
+
+---
+
+
+## 9. Reporting Issues
+
+1. **Open a New Issue**: [Click here](https://github.com/ni/labview-icon-editor/issues/new/choose) to file a bug or unexpected behavior. Provide as many details as possible—LabVIEW version, steps to reproduce, logs/screenshots, etc.
+2. **Label Decision**: The Steering Committee triages the issue. If it’s ripe for external help, they label it `Workflow: Open to contribution`.
+3. **Get Assigned**: Comment on the issue if you want to fix it; the maintainers assign you.
+4. **Implementation**: Work on the newly created or designated feature branch.
+5. **Pull Request**: Submit your changes, sign the CLA if needed, and wait for the `.vip` tests to confirm everything.
+
+---
+
+
+## 10. Code of Conduct
+
+All interactions—whether on GitHub or Discord—must follow our [Code of Conduct](https://github.com/ni/labview-icon-editor/blob/main/CODE_OF_CONDUCT.md). We strive to maintain a welcoming community. Please be respectful, inclusive, and considerate in all your contributions.
+
+---
+
+## Thank You!
+
+Your feedback, testing, and contributions (code or otherwise) directly improve a tool that thousands of LabVIEW users rely on every day. Whether you fix a minor bug, propose a new feature, or simply validate a `.vip` build, **you** help shape the future of the LabVIEW Icon Editor.
+
+Feel free to reach out on [Discord](https://discord.gg/q4d3ggrFVA) if you have questions or want to collaborate. Happy contributing!
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
new file mode 100644
index 00000000..c34ebb1e
--- /dev/null
+++ b/GOVERNANCE.md
@@ -0,0 +1,179 @@
+# NI Open Source Initiative Bylaws (DRAFT)
+
+*Last Updated: March 21, 2025*
+
+**Lightweight governance guidelines for National Instruments (NI) open source projects** – This document outlines how NI’s open source projects are managed in a transparent, collaborative way. It is intended for both external contributors and NI internal maintainers across all NI open source repositories (not just LabVIEW-related projects). These bylaws are not formal legal rules, but rather a common understanding to help our community work together effectively.
+
+## Table of Contents
+- [Scope and Purpose](#scope-and-purpose)
+- [Roles and Responsibilities](#roles-and-responsibilities)
+ - [NI Open Source Program Managers](#ni-open-source-program-managers)
+ - [Steering Committee](#steering-committee)
+ - [Project Maintainers](#project-maintainers)
+ - [Contributors](#contributors)
+- [Governance and Decision-Making](#governance-and-decision-making)
+ - [Technical Decisions and Changes](#technical-decisions-and-changes)
+ - [Project Proposals and New Repositories](#project-proposals-and-new-repositories)
+ - [Meetings and Communication](#meetings-and-communication)
+- [Contribution Process](#contribution-process)
+- [Code of Conduct and Enforcement](#code-of-conduct-and-enforcement)
+- [Amending These Bylaws](#amending-these-bylaws)
+
+## Scope and Purpose
+
+These bylaws apply to all open source projects under the NI GitHub organization. They provide a framework for how decisions are made, how contributors interact, and how leadership roles function across projects. Every NI open source repository (for example, the LabVIEW Icon Editor and others) should follow these guidelines, ensuring consistency and fairness in how we collaborate.
+
+The purpose of this document is to make governance clear and accessible. It describes who is responsible for what (from NI Open Source Program Managers to volunteer contributors) and how we work together. By keeping our governance lightweight and transparent, we encourage broad participation and smooth project operations. **Everyone – NI employees, community members, and users – should feel empowered to contribute and understand how decisions are made.**
+
+## Roles and Responsibilities
+
+Our open source community includes various roles, each with specific responsibilities. We emphasize clarity in these roles so that everyone knows how to participate and who to turn to for guidance or decisions. NI Open Source Program Managers and the Steering Committee have special leadership duties, while Maintainers and Contributors handle the day-to-day development and collaboration.
+
+### NI Open Source Program Managers
+
+NI Open Source Program Managers (OSPMs) are NI employees who oversee the health and process of NI’s open source initiatives. They act as coordinators and facilitators rather than traditional “bosses.” Their responsibilities include:
+
+- **Strategic Oversight:** Ensuring that each project aligns with NI’s open source strategy and values. OSPMs help decide, in coordination with the Steering Committee, which projects to open source and how they evolve.
+- **Support & Resources:** Providing maintainers and contributors with the support they need. This can include arranging access to tools, facilitating CI/CD resources, and helping with things like licensing or legal questions.
+- **Process Stewardship:** Making sure projects adhere to these bylaws and follow consistent processes. For example, OSPMs check that every repo has necessary files like a [README.md](README.md), [CONTRIBUTING.md](CONTRIBUTING.md), and [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
+- **Facilitating Decisions:** Assisting in decision-making when consensus is difficult to reach. OSPMs do not typically dictate technical decisions, but they help the community come to an agreement. In rare cases (e.g. a stalemate), an OSPM may act as a tie-breaker or appoint a mediator.
+- **Code of Conduct Enforcement:** Alongside the Steering Committee, ensuring the community stays welcoming and respectful. If serious issues arise (like a violation of the Code of Conduct), OSPMs help investigate and resolve them per the guidelines in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
+
+Overall, NI Open Source Program Managers are champions of open source culture within NI. They bridge internal NI teams and the external community, making sure contributors have a positive experience. They also handle any internal NI requirements (such as legal compliance or contributor license agreements) behind the scenes so that contributors can focus on what they do best.
+
+### Steering Committee
+
+The **Steering Committee** is a group of experienced project leaders (both NI staff and, optionally, community experts) who guide the technical direction and governance of NI open source projects. This committee works as a team to make collaborative decisions for the benefit of the projects and community. Key aspects of the Steering Committee’s role:
+
+- **Composition:** The committee typically includes NI Open Source Program Manager(s), lead maintainers from important projects, and possibly notable external contributors. Membership is based on merit and interest – individuals who have demonstrated commitment and expertise may be invited to join. We aim for a mix of NI insiders and community members to balance perspectives.
+- **Technical Guidance:** Steering Committee members collectively set the overall vision and priorities for projects. They evaluate proposals for major new features or new open source releases. For example, if someone proposes a significant change or a new repository to be open-sourced, the Steering Committee will discuss its fit with our goals.
+- **Decision Authority:** The committee makes decisions on high-level or cross-project matters. Wherever possible, decisions are made by consensus (general agreement). If consensus can’t be reached, the committee may call a simple majority vote among members to decide. The tone is collaborative – formal votes are a last resort. The Steering Committee’s goal is to reflect community input in all decisions.
+- **Issue Triage & Workflow:** In practice, the Steering Committee might help triage important issues or designate certain issues as high priority. In some projects, they label issues as “Workflow: Open to contribution” (or similar) to signal that external contributors are welcome to work on them. They also review and approve significant changes: for instance, final review of a major pull request or deciding when a feature is ready to merge. Steering Committee approval may be required for changes that affect multiple projects or have broader impact.
+- **Mentorship & Community Health:** Members serve as mentors and leaders in the community. They help new contributors find their footing, encourage diverse input, and ensure that discussions remain productive and respectful. If conflicts arise among contributors or maintainers, the Steering Committee can step in to mediate (always with reference to our Code of Conduct).
+
+The Steering Committee is essentially the “brain trust” of NI’s open source efforts. However, it operates openly: discussions and decisions should be visible to the community (through meeting notes, GitHub issues, or other public forums). This transparency helps build trust. The committee does not control day-to-day development – that’s up to maintainers and contributors – but it provides guidance and oversight to keep projects on track with their objectives.
+
+### Project Maintainers
+
+Project Maintainers are the people with direct responsibility for the upkeep of a specific repository. Maintainers can be NI employees or community members (or both). They have write access to the repository (i.e., they can merge pull requests) and are expected to drive the project forward. Responsibilities of maintainers include:
+
+- **Code Review & Merging:** Reviewing contributions (pull requests) from the community and other team members. Maintainers ensure that code meets quality standards, is well-tested, and aligns with the project’s goals. They merge changes into the codebase when they are satisfied with the contribution.
+- **Guiding Contributors:** Acting as the first point of contact for contributors. Maintainers should respond to issues and questions, label and organize issues appropriately, and help contributors understand the development workflow (for example, referring them to [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines).
+- **Upholding Standards:** Enforcing project standards for code style, documentation, and testing. They use tools and workflows (such as continuous integration checks defined in the repository’s [workflows](.github/workflows/) directory) to automate quality control. Maintainers make sure all tests pass and that each contribution doesn’t break the build or introduce licensing issues.
+- **Planning & Roadmap:** Collaborating on the project’s direction. Maintainers often propose new features or enhancements and discuss them with the community. They maintain a rough roadmap (which might be documented in issues, a `ROADMAP.md`, or simply via milestones in the issue tracker) so that contributors know where the project is heading.
+- **Coordination with Steering Committee:** For big decisions or uncertain areas, maintainers loop in the Steering Committee. While maintainers handle most day-to-day decisions, they recognize when an issue needs broader input (for example, a change that could affect multiple NI projects or that might be controversial). In those cases, maintainers will raise the topic with the Steering Committee for guidance.
+
+In short, maintainers keep the project healthy and moving. They are trusted members who have demonstrated ability to manage the codebase responsibly. Their actions are always in service of the community – maintainers are there to enable contributions, not to block them. By being accessible and responsive, maintainers make it easier for newcomers to join and for the project to benefit from outside ideas.
+
+### Contributors
+
+**Contributors** are anyone in the community who contributes to the project in any way. This includes writing code or documentation, filing bug reports, participating in discussions, or giving feedback. Contributors can be external community members or NI employees acting outside of a formal maintainer role. Here’s what we expect (and appreciate) from contributors:
+
+- **Follow Contribution Guidelines:** Before contributing code or documentation, contributors should read the [CONTRIBUTING.md](CONTRIBUTING.md) for the project. This will explain how to set up the environment, the coding standards, how to run tests, and the process for submitting changes. By following these guidelines, contributions can be reviewed and accepted faster.
+- **Open Collaboration:** We encourage contributors to discuss their ideas by opening issues or joining existing discussions. If you have a big idea or a feature request, feel free to start a conversation about it. In some cases, the Steering Committee or maintainers might suggest writing a proposal or design document (for example, adding an entry to an upcoming `EXPERIMENTS.md` for major experimental features) – but for most enhancements, a simple issue conversation is enough.
+- **Quality and Testing:** Contributors should ensure their work meets the project’s quality standards. This means writing clear code (or docs), and including tests for new functionality when appropriate. Our automated CI checks (see the project’s [workflows](.github/workflows/) for details on builds and tests) will run on each pull request to help validate this. Don’t worry – maintainers will help if something fails or if changes are needed.
+- **Respect and Professionalism:** All contributors must adhere to our [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md). In practice, this means being respectful in communications, providing constructive feedback, and being open to feedback on your own contributions. Healthy, civil discussions are key to a thriving community. If you’re not sure about something, ask! We’re all here to learn and improve the project together.
+
+Every contribution, no matter how small, is valuable. Whether you found a typo in the documentation or you’re adding a major new feature, you are part of the community. We thank our contributors by acknowledging them in release notes or README, and outstanding contributors may be invited to become maintainers or even join the Steering Committee over time. Our goal is to make contributing rewarding and fun, with as little friction as possible.
+
+## Governance and Decision-Making
+
+We strive for a governance model that is lightweight and responsive. Most daily decisions are made by those closest to the work (maintainers and contributors). Larger decisions that affect the direction of a project or the NI open source ecosystem as a whole involve the Steering Committee and Program Managers. The guiding principle is **consensus and transparency**: we prefer to discuss things openly and come to agreement, rather than impose rules from the top down.
+
+### Technical Decisions and Changes
+
+For technical decisions within a project (like implementing a new feature, changing a dependency, modifying architecture, etc.), the process generally works as follows:
+
+- **Proposal and Discussion:** Ideas can come from anyone. Typically, a contributor or maintainer will open a GitHub Issue or Discussion thread to propose a significant change. This is a space to discuss the idea’s merits, alternatives, and potential impacts. Everyone is welcome to voice opinions, and we especially encourage input from those who would be affected by the change (users of the project, other maintainers, etc.).
+- **Seeking Consensus:** Maintainers aim to build consensus on the proposal. If most people agree and no one has strong objections, we consider that a consensus. The idea may be refined through feedback during this stage. Small changes can reach consensus quickly, while bigger ones might need more time and input.
+- **Steering Committee Input (if needed):** If a proposal is particularly large in scope, risky, or affects multiple projects, the Steering Committee will get involved. They might join the discussion in the issue, or discuss it in a Steering Committee meeting and then post their recommendations. The committee’s role here is to ensure the change aligns with project goals and to raise any high-level concerns.
+- **Decision and Implementation:** In most cases, maintainers will make the call to move forward with a change once there’s general agreement. They might say “We’ve incorporated feedback and it looks like we have consensus to proceed.” Then the change can be implemented (e.g., a contributor is asked to create a PR, or if one already exists, it’s updated and reviewed). If there are lingering disagreements, maintainers and possibly the Open Source Program Manager will work to address them. As a last resort, if consensus isn’t reached, a majority vote among the Steering Committee or a decision by the Program Manager/Lead Maintainer can be used to finalize the direction.
+- **Documentation of Decision:** Any major decision should be documented for posterity. This could be done by updating relevant documentation (like adding an entry to `CHANGELOG.md` or an upcoming `EXPERIMENTS.md` if the feature is experimental, or simply leaving the issue open with a summary of the final decision). Transparency is critical – even decisions made after lengthy debate should be clearly communicated to everyone.
+
+The above process is meant to be natural and not overly bureaucratic. Many changes, especially minor ones, will flow through quickly with maintainers merging pull requests once tests pass and reviews are done. We mostly invoke the formal “decision-making” steps for big matters where community input is important. Our default is trust: we trust maintainers to handle routine decisions, and maintainers trust contributors to submit improvements in good faith. When in doubt, open communication ensures we get it right.
+
+### Project Proposals and New Repositories
+
+From time to time, NI (or community members in partnership with NI) may want to open source a new project or create a new repository under the NI GitHub organization. The process for proposing a new project or significant initiative is as follows:
+
+1. **Draft a Proposal:** The person or team proposing the new project should draft a brief description of the project’s scope, goals, and why it should be open-sourced. This could be done in a GitHub Discussion or a document shared with the Steering Committee. (Eventually, we may have a template for such proposals or an `EXPERIMENTS.md` to capture ideas that are being tried out.)
+2. **Review by Program Managers and Steering Committee:** NI Open Source Program Managers will review the proposal first to ensure it aligns with NI’s strategy and resources (for example, verifying that NI can support the project long-term, or that it doesn’t conflict with any licensing concerns). Then the Steering Committee will evaluate the technical merits and community interest. Key questions include: Is there a clear benefit to open sourcing this? Are there maintainers available to steward it? Does it fit well with our other projects?
+3. **Community Input:** If appropriate, the proposal may be shared publicly (for example, if it’s an addition to an existing product line or something users have asked for). Community feedback can be gathered via comments. This isn’t always necessary (for example, if NI decides to open source an internal tool, the initial decision might be mostly internal), but we prefer to gauge interest whenever possible.
+4. **Decision:** The Steering Committee, with recommendation from the Program Managers, will make the final call. If there’s strong agreement, the project gets a green light. The decision will be documented (through meeting notes or an announcement in the Discussions forum of a relevant repo). If the proposal is declined or postponed, we will communicate the reasons to maintain transparency.
+5. **Bootstrap the Project:** If approved, initial repository setup will be done. This includes creating the repo (under github.com/ni), adding standard files like README, CONTRIBUTING, LICENSE, CODE_OF_CONDUCT, etc., and populating it with the initial code drop. The new project will then follow the same bylaws as others. The proposers might become the first maintainers, and the Steering Committee will oversee its integration into the broader NI open source ecosystem.
+
+For major new features within an existing project, a lighter version of the above may occur: for example, the maintainers and Steering Committee might treat a big new subsystem as an “experimental feature”. They could use an `EXPERIMENTS.md` (if available) to outline the plan and get feedback, then develop it in a separate branch or behind a feature flag until it’s stable.
+
+In summary, new ideas are welcome! We just ensure there’s enough discussion and planning so that new projects or features start off on the right foot, with community buy-in and clarity on who will maintain them.
+
+### Meetings and Communication
+
+**Communication is open by default.** The majority of project communication happens in public channels, primarily on GitHub:
+- **Issues and Discussions:** We use GitHub Issues to track bugs, tasks, and proposals. GitHub Discussions (if enabled on the repo) or external forums can be used for broader conversations, Q&A, or brainstorming. Everyone is free to participate here, and all significant technical discussions should be documented in these channels so others can follow along.
+- **Pull Request Feedback:** Code review comments in pull requests are another key form of communication. We keep these constructive and on-topic. It’s fine to have detailed technical debates in PRs — that ensures decisions around code changes are captured in context.
+
+The Steering Committee and Program Managers may also have periodic meetings to coordinate across projects:
+- **Steering Committee Meetings:** These might be monthly or quarterly (depending on need). In the spirit of transparency, we aim to at least partially conduct these in the open. For example, the committee might meet via a call (with internal notes), but then publish a summary of decisions/outcomes publicly. If feasible, some meetings could even be open to observers or have an open portion for community questions.
+- **Meeting Notes:** All decisions or important points from Steering Committee meetings will be posted in a public place (such as a `governance` repo, a `MEETINGS.md` file, or a Discussion post). This way, even community members who weren’t present can stay informed about what was discussed and decided.
+- **Ad-hoc Discussions:** Program Managers and maintainers sometimes need to discuss things in real time (for example, via an NI-internal channel or a private Slack) – especially for urgent issues like security disclosures or incidents. However, any decisions affecting the project will be brought back to the public channels as soon as possible. We avoid “closed-door” decision making; even if initial discussion is private, the outcome should be shared openly once ready.
+
+Additionally, NI may provide or support certain communication platforms for the community:
+- **Chat (Discord/Slack):** For more casual or quick exchanges, we might use a public chat channel (for instance, some projects have a Discord server or NI Community forum). These are great for user support, quick questions, or brainstorming. They do not replace GitHub for decision-making, but they help build community.
+- **Mailing Lists/Newsletter:** If appropriate, a mailing list or periodic newsletter could be used to update interested people on project progress, releases, and upcoming discussions. Subscribing to these would be optional for those who prefer email updates.
+
+In all communications, we remind everyone to keep the tone friendly, professional, and inclusive. Disagreements are fine, but we debate ideas, not personalities. Our [Code of Conduct](CODE_OF_CONDUCT.md) applies in all forums. If you witness or experience any harassment or improper behavior, report it to the maintainers or Program Managers — we will address it confidentially and seriously.
+
+Effective communication ensures that everyone moves in the same direction and feels included. We encourage questions, suggestions, and even constructive criticism. Good ideas can come from anywhere, and by communicating openly, we increase the chances of catching them.
+
+## Contribution Process
+
+Each NI open source repository provides specific instructions for contributing (see the project’s individual [CONTRIBUTING.md](CONTRIBUTING.md) file for details). However, there are common principles across all projects, which we summarize here for clarity. The contribution process is designed to be as straightforward as possible:
+
+1. **Find an Issue or Idea:** To start contributing code or documentation, find something you’d like to work on. This could be an open issue labeled “help wanted” or “good first issue,” or maybe you have a new idea to propose. Maintainers and the Steering Committee often label issues (e.g., `Workflow: Open to contribution`) to signal that community contributions are welcome on those. If you have a totally new idea, consider opening a new issue to discuss it first.
+2. **Fork & Branch:** Fork the repository to your own GitHub account and create a new branch for your work (or if you have push access as a maintainer, create a feature branch on the main repo). Give the branch a descriptive name (e.g., `feature/add-plot-widget` or `bugfix/fix-memory-leak`).
+3. **Write Code or Content:** Implement your changes following the project’s coding standards and style. If adding a feature or fixing a bug, try to include tests that verify the behavior (if the project has a test suite). For documentation changes, ensure clarity and proper formatting. Don’t forget to run the project locally if applicable, to manually test your changes.
+4. **Continuous Integration Checks:** When you push your changes and open a Pull Request (PR), automated workflows will run (usually visible in the PR checks section). These might include building the project, running unit tests, linting the code style, etc. Our CI is configured via GitHub Actions workflows (see the YAML files in the [workflows](.github/workflows/) directory for what’s being checked, such as build verification and unit tests). Ensure your changes pass these checks. If something fails, you can push additional commits to fix the issues – maintainers can help interpret failures if you’re stuck.
+5. **Pull Request Review:** Maintainers (and possibly other community members) will review your PR. They might request changes or provide feedback. This is a normal part of the process to maintain quality and consistency. Try to respond to feedback in a timely manner by making the requested updates or discussing further if you disagree (politely, of course). Remember, we’re all aiming to improve the project together.
+6. **Approval and Merge:** Once your contribution is reviewed and approved (usually at least one maintainer will approve it), it will be merged into the codebase. We prefer the “squash and merge” approach for external contributions – this keeps the history clean – but maintainers will choose whatever method makes sense for the project. You’ll get credit in the commit history and release notes. Congratulations, you’ve contributed!
+7. **Continuous Improvement:** After merge, if any issues arise (maybe a bug was found in your feature, or a follow-up change is needed), don’t be discouraged. We will work together to address them. Open source is an iterative process. Similarly, even if your PR isn’t accepted initially, we appreciate the effort – maintainers will explain why and often suggest how you might adjust it for future consideration.
+
+Beyond code, you can contribute by helping with documentation, answering questions from other users, or sharing ideas. All forms of contribution are valuable. For large contributions or changes, you might be asked to sign an NI Contributor License Agreement (CLA) to confirm you are entitled to contribute the code – see the project’s contributing guidelines for how NI handles CLAs. (Typically, when you open a PR for the first time, a bot will check this and provide instructions if a CLA signature is needed.)
+
+Our goal is to make contributing easy and rewarding. We welcome first-time contributors and will happily mentor you through your initial contributions. The community thrives when more people get involved, so we aim to eliminate unnecessary barriers. If anything in the contribution process is unclear or not working, please let us know – we are open to adjusting our process based on contributor feedback.
+
+## Code of Conduct and Enforcement
+
+All NI open source projects adhere to a common **Code of Conduct** (see [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) in this repository). This is a vital part of our community guidelines. It sets the expectation that everyone interacts with respect and professionalism. We absolutely want our projects to be welcoming spaces for all developers and users.
+
+**Key points of the Code of Conduct:**
+- Be respectful and inclusive. Discrimination, harassment, or abusive behavior will not be tolerated.
+- Communicate with empathy. Remember there are real people behind the comments and code. Try to understand differing viewpoints and handle disagreements civilly.
+- Focus on what is best for the community and project. We’re all here to make the software better and help each other.
+
+If someone’s behavior violates these principles, we have a clear path to address it:
+- **Reporting Issues:** Anyone who experiences or witnesses a Code of Conduct violation should feel safe to report it. The Code of Conduct file provides contact information (often an email for the maintainers or NI Open Source Program Manager). You can also privately contact an NI Open Source Program Manager or Steering Committee member to report concerns. All reports will be handled confidentially.
+- **Enforcement Process:** Upon receiving a report, the Program Managers (and if needed, the Steering Committee) will review the situation. We follow the process outlined in the Code of Conduct document, which typically involves reaching out to the person reported, understanding the facts, and deciding on appropriate action. For minor issues, a friendly reminder or warning might be sufficient. For serious misconduct, actions can range from temporary suspension from project participation to a permanent ban from the community.
+- **Resolution and Follow-up:** We commit to resolving Code of Conduct issues promptly and fairly. Once a decision is made, the affected parties will be informed. We won’t publicly shame anyone; however, if someone is removed from the community, other members may be informed that the person will no longer be participating (without divulging private details). Our goal is always to restore a healthy environment. In some cases, that may involve mediation or setting specific expectations for future behavior if the person remains in the community.
+
+The Steering Committee is empowered to enforce the Code of Conduct, and NI Open Source Program Managers back them up with institutional support. This might include consulting NI’s HR or legal teams if an incident is extreme (especially if it involves an NI employee), but generally, the community leaders will handle it internally.
+
+We also emphasize education and improvement. If someone makes a mistake and is willing to learn and apologize, we welcome that. We’re all human, and we’d rather help someone align with our values than simply punish. However, we have zero tolerance for repeated or severe violations that jeopardize community safety.
+
+By referencing the Code of Conduct throughout these bylaws, we ensure that **respect and kindness** remain core to how we operate. It’s not just about handling violations after the fact, but about fostering a culture where problems are less likely to occur. Thank you to everyone for contributing to this positive environment.
+
+## Amending These Bylaws
+
+These bylaws are meant to be a living document. As our community grows and learns, we may find that parts of this governance model need to evolve. Changes to this document can be proposed by anyone, but will be enacted through a lightweight, collaborative process:
+
+- **Proposal for Change:** If you think an update or addition to the bylaws is needed, start by opening an issue or discussion suggesting the change. Clearly describe what you want to change and why. For example, maybe you think we should clarify the role of a “Lead Maintainer” or add a section about handling security vulnerabilities. Any community member (NI or external) can make a suggestion.
+- **Discussion and Review:** The suggestion will be discussed openly. NI Program Managers and the Steering Committee will definitely weigh in, since they have a broad view of how the governance works across projects. Maintainers and contributors are encouraged to give feedback too – after all, the bylaws affect everyone. We’ll consider whether the change makes our processes better, more clear, and more inclusive.
+- **Drafting the Revision:** If there’s general agreement to proceed, a draft of the updated text will be prepared (this could be a pull request editing this Markdown file). We prefer to get consensus on the concept first, then fine-tune the wording. The draft can be iterated with feedback in the PR comments.
+- **Approval:** To officially adopt the change, we’ll need approval from the Steering Committee and at least one NI Open Source Program Manager. In practice this could mean a PR is approved by those folks. If it’s a significant change, they might also announce it on the mailing list or Discussions for broader awareness before finalizing. Minor edits (like fixing typos or updating examples) can be approved with a lighter review (e.g., just a maintainer).
+- **Transparency:** Once merged, the updated bylaws should be communicated. This could be as simple as a changelog entry in the commit message or a note in an upcoming community meeting. We might tag a new release of documentation if that’s relevant. The point is to ensure people know the rules have changed. In the document’s header (like at the top of this file), we’ll update the “Last Updated” date so it’s clear when the last change occurred.
+
+We want the amendment process itself to embody the openness we aim for. Nothing here is set in stone forever, and good ideas to improve our governance are welcome. However, changes shouldn’t be made lightly – our bylaws work well when they’re consistent and understood by all. So, we balance adaptability with stability.
+
+By following a collaborative change process, we ensure that the bylaws continue to serve the community’s needs and that everyone has a voice in shaping our project governance. In essence, **these bylaws belong to the community**: let’s keep them useful, clear, and in tune with how we actually work together.
+
+---
+*© 2025 National Instruments Corporation. This document is open source (feel free to reuse/adapt it for your own communities). It is provided as guidance for collaborative development and does not constitute legal advice.*
diff --git a/README.md b/README.md
index a3cb4196..99274365 100644
--- a/README.md
+++ b/README.md
@@ -1,83 +1,161 @@
-# Icon Editor for LabVIEW #
+# LabVIEW Icon Editor
-This repo contains the source files and automated build tools for the LabVIEW icon editor.
-You can use this code as a starting point for creating a custom icon editor. Refer to the [CONTRIBUTING](CONTRIBUTING.md) document for information about submitting changes for inclusion with future versions of LabVIEW.
+[](https://github.com/ni/labview-icon-editor/actions/workflows/build-vi-package.yml)
-## Compatible LabVIEW Versions
-LabVIEW source is saved in 21.0 (__LabVIEW 2021__) format. Either LabVIEW 2021 or LabVIEW 2024 can be used to do development work.
+---
-To build using the automated build process, ensure you have LabVIEW 2021 *both 32 and 64 bits* installed, latest VIPM, and apply the dependencies located on *Tooling\deployment\Dependencies.vipc* to both LabVIEW versions.
+## Table of Contents
+1. [Overview](#overview)
+2. [Key Components](#key-components)
+3. [Getting Started & Contributing](#getting-started)
+4. [Feature & Experiment Workflows](#feature-dev-workflow)
+5. [Documentation](#documentation)
+6. [Technical Steering Committee](#steering-committee)
+7. [License & CLA](#license-cla)
+8. [Contact & Discord](#contact-discord)
-## Editing Guide
+---
-Because the icon editor is part of the LabVIEW development environment, you need to make changes to installed files before editing this project. There is an manual process, and an automated process made following it for ease of use.
+
+## 1. Overview
-### Automated process
+This repository hosts the **open-source LabVIEW Icon Editor** under an **MIT license**. Whenever **LabVIEW** is built for an official release, it automatically pulls the **latest** Icon Editor from this repo’s `main` branch. This means that **your contributions**—whether features, bug fixes, or documentation—can become part of **official LabVIEW distributions** (currently focusing on **LabVIEW 2021–2025**).
-Before following this process, create a backup of the following files and folder:
- - \\\resource\\plugins\\lv_icon.lvlibp
- - \\\vi.lib\\LabVIEW Icon API\\*
+### Current Pre-Release
+- **Green default theme** for testing (feel free to revert/customize!)
+- LabVIEW **2021–2025** version specificity is important for technical reasons within this editor’s packaging approach.
-After cloning the repo into a development location, and applying the dependencies located on *Tooling\deployment\Dependencies.vipc* to LabVIEW 2021 32 and 64 bits, follow this process to use the automation layer.
+NI is eager to see **community collaboration** drive improvements, ensuring the Icon Editor remains robust and innovative.
-1. Open Powershell in *Admin* mode and navigate to *.pipeline\scripts* from your github repo.
-2. Modify the following command to point to your github repo and run it: *.\DevelopmentMode.ps1 -RelativePath "C:\labview-icon-editor"*
-3. Open lv_icon_editor.lvproj in LabVIEW.
-4. The top-level VI is in the Project Explorer at __My Computer » resource/plugins » lv_icon.lvlib » lv_icon.vi__.
+---
-### Manual process
+
+## 2. Key Components
-Complete the following steps to edit this project:
-1. Clone this repo into a development location (e.g., C:\dev).
-2. Run __Tooling\Prepare LV to Use Icon Editor Source.vi__.
-This will perform the following steps, which you can alternatively perform manually:
- * Delete \\\resource\\plugins\\lv_icon.lvlipb
- * Delete \\\vi.lib\\LabVIEW Icon API
- * Set LocalHost.LibraryPaths in your labview.ini file to the location of this project. For example:*
- * LocalHost.LibraryPaths="C:\\dev\\labview-icon-editor"
-3. Open lv_icon_editor.lvproj in LabVIEW.
-4. The top-level VI is in the Project Explorer at __My Computer » resource/plugins » lv_icon.lvlib » lv_icon.vi__.
+1. **Source Files**
+ - Entirely **VI-based**, enabling customizations and enhancements to the Icon Editor’s UI and functionality.
-## Distribution Guide
+2. **PowerShell Automation**
+ - Built on [G-CLI](https://github.com/G-CLI/G-CLI).
+ - Handles build, packaging, and release tasks.
+ - Easily integrated into DevOps (GitHub Actions, self-hosted runners).
-Complete the following steps to distribute your custom icon editor to another machine.
+3. **CI/CD Workflows**
+ - [Build VI Package](https://github.com/ni/labview-icon-editor/actions/workflows/build-vi-package.yml)
+ - [Development Mode Toggle](https://github.com/ni/labview-icon-editor/actions/workflows/development-mode-toggle.yml)
+ - [Run Unit Tests](https://github.com/ni/labview-icon-editor/actions/workflows/run-unit-tests.yml)
-### Automated process
+These pipelines produce **.vip** artifacts so anyone can install and test changes in their **LabVIEW 2021–2025** environment.
-This automated build process will follow these steps:
+---
-1. Apply the dependencies
-2. Run the unit test,
-build the icon editor packed project library
+
+## 3. Getting Started & Contributing
-1. Open powershell in *Admin* mode and navigate to *.pipeline\scripts* from your github repo.
-2. Modify the following command to point to your github repo and run it:
- ```bach
- .\build.ps1 -RelativePath "C:\labview-icon-editor"*
- ```
-4. A VI package named *ni_icon_editor-x.x.x.x* will be built on *builds\VI Package*.
-5. You can now install this VI package on any LabVIEW version after 2020.
+We welcome **code** and **non-code** contributions—everything from bug fixes and performance tweaks to testing `.vip` files or improving documentation.
-*NOTE: The VI package makes no backup of your current lv_icon.lvlibp because the VI Package itself contains a zip file with all combinations of lv_icon.lvlibp for all LabVIEW versions and bitnesses, which gets deployed to your LabVIEW application files on uninstall. This ensures that a user doesnt get locked out of his icon editor and having to copy it from another LabVIEW installation if somehow he deletes the backup he did manually.*
+- **Must sign a CLA**: For external contributors, we require a Contributor License Agreement before we can merge your pull requests.
+- **Steering Committee**: A group of NI staff + community experts steers features. If an issue is labeled "`Workflow: Open to contribution`," it’s ready for external work.
+- **Fork or Clone**: Start by forking (or cloning) this repo. Then pick an issue or propose a feature.
+- **Experiments**: If you have a **long-lived** or large-scale feature (spanning weeks or months), see [EXPERIMENTS.md](docs/ci/experiments.md). Experimental branches might require special approval before `.vip` distribution is enabled.
-### Manual process
+For more details on the standard process, see our [CONTRIBUTING.md](CONTRIBUTING.md).
-First, build the __Editor Packed Library__ build specification in the project to create __lv_icon.lvlibp__.
+---
-Then, on the machine where you want to install your custom icon editor:
-1. Rename __\\\resource\\plugins\\lv_icon.lvlibp__, the shipping icon editor, to __lv_icon.lvlibp.ship__ to "hide" it.
-2. Archive __\\\vi.lib\\LabVIEW Icon API__ to preserve the shipping copy. Use your archive program of choice (e.g. 7-Zip).
-3. Copy the packed library and support files that you developed with this project into the \ directory:
- - \\\resource\\plugins\\lv_icon.lvlibp
- - \\\vi.lib\\LabVIEW Icon API\\*
+
+## 4. Feature & Experiment Workflows
-## CI using an Azure DevOps pipeline
+### Standard Feature Workflow
-An Azure Devops pipeline is used as an additional check to approve pull requests from *feature* to *development* branches. This pipeline runs the unit tests, builds the packed project libraries for both 32 and 64 bit LabVIEW, and builds the VI Package.
+1. **Check or Create an Issue**
+ - If you have an idea, discuss it on [Discord](#contact-discord) or open a GitHub Discussion.
+ - Once it’s approved, the Steering Committee labels it "**Workflow: Open to contribution**."
-## CI using github actions
+2. **Assignment**
+ - Comment on the issue expressing interest in developing the feature.
+ - The Steering Committee (or a maintainer) assigns you.
-An example of a github action that can manually trigger a CI/CD workflow is located at "C:\labview-icon-editor\.github\workflows\Build VI packages.yml"
+3. **Branch Setup**
+ - A feature branch is created.
+ - Fork + clone the repo, checkout the feature branch, implement changes.
+4. **Build & Test**
+ - Decide between [Manual Setup](./docs/manual-instructions.md) or [PowerShell Scripts](./docs/powershell-cli-instructions.md).
+ - Our CI pipeline generates a `.vip` so others can confirm your feature works in **LabVIEW 2021–2025**.
+5. **Pull Request**
+ - Open a PR referencing the issue.
+ - Sign the CLA if needed.
+ - The Steering Committee + maintainers review, test, and iterate.
+
+6. **Merge & Release**
+ - Once approved, your changes merge into `develop` or a typical short-lived branch.
+ - Eventually, everything merges to `main`, ready for the **official** LabVIEW build cycle.
+
+### Experimental Branch Workflow
+
+For **long-running** or **complex** features, see [EXPERIMENTS.md](docs/ci/EXPERIMENTS.md).
+- **Docker VI Analyzer** & CodeQL run automatically on experimental branches, but distributing `.vip` artifacts requires NI’s **manual approval** (“approve-experiment” event).
+- Alpha/Beta/RC sub-branches are optional for staging within the experiment.
+- Final merges also go through the Steering Committee.
+
+---
+
+
+## 5. Documentation
+
+Check out our docs folder for detailed guides:
+
+- **[Build VI Package](docs/ci/actions/build-vi-package.md)** – Automate release processes for LabVIEW-based projects (2021–2025).
+- **[Development Mode Toggle](docs/ci/actions/development-mode-toggle.md)** – Enable/disable dev mode on a self-hosted runner.
+- **[Multichannel Release Workflow](docs/ci/actions/multichannel-release-workflow.md)** – Handle alpha, beta, RC channels, plus final versions.
+- **[Runner Setup Guide](docs/ci/actions/runner-setup-guide.md)** – Steps for self-hosted runners with GitHub Actions.
+- **[Injecting Owner/Repo Into VI Package](docs/actions/injecting-repo-org-to-vi-package.md)** – Add unique repo/org metadata to .vip.
+- **[Troubleshooting & FAQ](docs/ci/troubleshooting-faq.md)** – Common issues, solutions, frequently asked questions.
+- **[Experiments.md](docs/ci/experiments.md)** – Detailed instructions for the GitFlow-like model for long-lived experimental features.
+- **[Maintainers_Guide.md](docs/ci/actions/maintainers-guide.md)** – Admin tasks for “approve-experiment” workflow dispatch, BDFL overrides, final merges.
+- **[Troubleshooting_Experiments.md](docs/ci/actions/troubleshooting-experiments.md)** – Common pitfalls specific to experimental branches.
+- **[Governance.md](./GOVERNANCE.md)** – Steering Committee, BDFL, and membership structure.
+
+---
+
+
+## 6. Technical Steering Committee
+
+- [@JayKayAce](https://github.com/JayKayAce)
+- [@crossrulz](https://github.com/crossrulz)
+- [@neilpate](https://github.com/neilpate)
+- [@j-medland](https://github.com/j-medland)
+- @markballa
+- [@RobustoSystems](https://github.com/RobustoSystems)
+
+**NI Open Source Program Manager**: [@svelderrainruiz](https://github.com/svelderrainruiz) – sergio.velderrain@emerson.com
+
+They review incoming PRs, decide on feature readiness, and merge changes once they pass testing. For **long-lived experiment** branches, see [EXPERIMENTS.md](docs/ci/experiments.md) for how they approve final merges or partial merges.
+
+---
+
+
+## 7. License & CLA
+
+- **MIT License**: The Icon Editor code is available under [MIT](LICENSE).
+- **Contributor License Agreement (CLA)**: Before merging external pull requests, we’ll ask you to sign a CLA to confirm we can distribute your code as part of LabVIEW.
+
+By contributing, you agree to license your work under these terms so NI and the LabVIEW community can incorporate improvements into future distributions.
+
+---
+
+
+## 8. Contact & Discord
+
+Have questions or want to discuss an idea in real-time?
+
+- **Discord Server**: [Join here](https://discord.gg/q4d3ggrFVA). You can brainstorm features, ask about the labeling workflow, or get quick help from fellow contributors.
+- **GitHub**: Use Issues, Discussions, or open a Pull Request directly.
+
+### Thanks for Contributing!
+Your submissions—whether bug fixes, docs, or experimental features—directly shape the **LabVIEW Icon Editor** for **LabVIEW 2021–2025** and beyond. We appreciate your collaboration and look forward to your ideas!
+
+---
diff --git a/Tooling/CI CD.lvproj b/Tooling/CI CD.lvproj
index a919a31d..8af423b0 100644
--- a/Tooling/CI CD.lvproj
+++ b/Tooling/CI CD.lvproj
@@ -15,13 +15,14 @@
false
-
-
+
+
-
+
-
@@ -31,360 +32,9 @@
+
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
- true
-
- -
- true
-
- -
- true
-
-
+
-
-
true
@@ -410,7 +60,7 @@
{35081879-4FB0-4AEF-A64A-5BD8095F0C7D}
Container
0
-
+ /
true
true
true
diff --git a/Tooling/PrepareIESource.vi b/Tooling/PrepareIESource.vi
index 2603d8a1..7d0861f0 100644
Binary files a/Tooling/PrepareIESource.vi and b/Tooling/PrepareIESource.vi differ
diff --git a/Tooling/PrepareIESourceCore.vi b/Tooling/PrepareIESourceCore.vi
new file mode 100644
index 00000000..f24aed7f
Binary files /dev/null and b/Tooling/PrepareIESourceCore.vi differ
diff --git a/Tooling/RestoreSetupLVSource.vi b/Tooling/RestoreSetupLVSource.vi
index b6036617..5f0f9305 100644
Binary files a/Tooling/RestoreSetupLVSource.vi and b/Tooling/RestoreSetupLVSource.vi differ
diff --git a/Tooling/RestoreSetupLVSourceCore.vi b/Tooling/RestoreSetupLVSourceCore.vi
new file mode 100644
index 00000000..835f742e
Binary files /dev/null and b/Tooling/RestoreSetupLVSourceCore.vi differ
diff --git a/Tooling/Unit tests/Missing PPLs on LV project.vi b/Tooling/Unit tests/Missing PPLs on LV project.vi
deleted file mode 100644
index d5d5c5b7..00000000
Binary files a/Tooling/Unit tests/Missing PPLs on LV project.vi and /dev/null differ
diff --git a/Tooling/Unit tests/Missing VIs or controls on LV project.vi b/Tooling/Unit tests/Missing VIs or controls on LV project.vi
deleted file mode 100644
index d7f6e618..00000000
Binary files a/Tooling/Unit tests/Missing VIs or controls on LV project.vi and /dev/null differ
diff --git a/Tooling/Unit tests/Missing classes on LV project.vi b/Tooling/Unit tests/Missing classes on LV project.vi
deleted file mode 100644
index 912733f7..00000000
Binary files a/Tooling/Unit tests/Missing classes on LV project.vi and /dev/null differ
diff --git a/Tooling/Unit tests/Missing in Project/Get Project MyComputer.vi b/Tooling/Unit tests/Missing in Project/Get Project MyComputer.vi
new file mode 100644
index 00000000..47e2fe48
Binary files /dev/null and b/Tooling/Unit tests/Missing in Project/Get Project MyComputer.vi differ
diff --git a/Tooling/Unit tests/Missing in Project/Missing in Project.lvclass b/Tooling/Unit tests/Missing in Project/Missing in Project.lvclass
new file mode 100644
index 00000000..8775f1b7
--- /dev/null
+++ b/Tooling/Unit tests/Missing in Project/Missing in Project.lvclass
@@ -0,0 +1,69 @@
+
+
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!)D!!!*Q(C=\>3R=>N!%)8B*Y]$J?T!QR;W"<<!&L9&JAT:QL<!&ND#;Y%NM!8YP_-;ZCA1!]FD"=,J)0$BM0="O)%UNV@JJZ:HW`(>\@HZ-7#BX1`(\P[LD__\?X<]MXM)_H$JK7;.>=4S70`PV=@FO/\7]_PU<_<`[0U^P@`X.XVPX^P`X:YPUH__:F]U0E2UUYO?^.#9;D'ZS5VO=J/<P-C,P-C,P-C,0-G40-G40-G40-C$0-C$0-C$@$:SE9N=Z*$-Z'9C5^15-)/BS/S-RXC-RXDY+?-R(O-R(O.BC)T(?)T(?)S(SW1]RG-]RG-]F*I3TU;/RXAIL]*4?!J0Y3E]4+H#5Q#+S9L#22%9+EY7"Y7H]"1?$F6Y#E`B+4S&B^-K0)7H]"3?QM-F][H5V)R'DI=S3DS**`%EHM2$;37?R*.Y%E`C94IFHM34)*)*E_)1F&S5$%B_**\%QT]FHM34?"*0YO(5@%-ZH]T1D%;/*`!%HM!4?!)0*22Y!E`A#4S"B\)+0)%H]!3?Q-.5#DS"*`!%E'"3JF>1,,AQ'"1%A9?`O6JCPK7;EJB.[M7L8J4KR;:?2/L&I8\J[J?J@EHKB[^_K/K(J8Y)[JN4I^59^34KC]>!X>B@[2@[G8[C(_B\_I[_J7`'J:]]](;\[8K^[H+Z[(Q_[X1[[8!Y;,`@;\@<;<P>;L0:L*_"8\4VA`!6PEN@QP"$DX6Z2L]"SZ1!-A!!!!!
+ 553680896
+ 1.0.0.0
+ true
+ true
+ true
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!".X5F.31QU+!!.-6E.$4%*76Q!!$PA!!!2`!!!!)!!!$NA!!!!@!!!!!2J.;8.T;7ZH)'FO)&"S<WJF9X1O<(:D<'&T=Q!!!!#A)1#!!!!Q!!!I!!1!!!!!"!!$!$Q!P!!@1)!#!!!!!!%!!1!'`````Q!!!!!!!!!!!!!!!([W+)4#3)B$N8`@Y!W`-HM!!!!-!!!!%!!!!!"T49$:5^9X2JVJ,NMZ."+*V"W-W9]!MA4JA!G9\0B#@A!!!!!!!!!!0CD34X*,JU'A=_(Z`PI:0!%!!!$`````V"W-W9]!MA4JA!G9\0B#@A!!!"$H9QD1CX[J)6T7WCL2:&RJ!!!!"!!!!!!!!!!H!!&-6E.$!!!!!1!#6EF-1A!!!!"16%AQ!!!!"1!"!!%!!!!!!A!$!!!!!!)!!1!!!!!!)A!!!"JYH'.A9W"K9,D!!-3-1-T5Q01$S0\!Q-!!!&;6"O9!!!!!!%-!!!%9?*RD9-!%`Y%!3$%S-,#!O#RIYG!;RK9GQ'5O,LOAYMR1.\*#2"G"9MQPA!QGE"SK8B9'*/`!!2M7MQ'&=#8Q!!!!!!Q!!6:*2&-!!!!!!!-!!!%`!!!$)(C=#W"E9#CP-$-29'*A9!;S&2E;'*,T5V+Z')"]"A4YQ]2!%7C!GK?&*GZYY(!;%/DRS\?!_2\.<T1]GX]QF1J[\)#J_8`"I`G)RG'0\E;1U('(",$#<E<$3[['"`Z0O!$7"F4!,_]!VN^1;=V1QGZY!#RYP0%,)]19$!."[H?!*!_DWO^R]"',*VSR6S],EV?S#*.(JQO8Q8%8LA!RE,*?%3[MZI5"$6$Q[$S(E.T&#&(2T9=1]_BU$%$B;3$T'C_AO"9I]!&>Y!(%TQJRBQE&0)FA\?N\OU$RR)9EZM!!C4]'*F3MR]$)!0)=C-S&KL5"MJGA9D*1-2"\,Z3NA;4H&J,Z-,&:9$51_VCB9O_A@"$\$Z!/A,+ZA*IG1.H31,9!F+U$:&_!O2=0\?TPYMK!*6UDJX5!4J>IXA!!!!!4!!!!#8C=9W"A9'2E!!)!!"1!!Q!!!!!/)1'!"A!!"D)R,D!O-1!!!!!!!!QB!)!!!!!%-D%O-!!!!!!/)1'!"A!!"D)R,D!O-1!!!!!!!!QB!)!!!!!%-D%O-!!!!!!/)1'!"A!!"D)R,D!O-1!!!!!!!"1"!!!!^6=VAHEGIIQO=V*/"EEZH1!!!!U!!!!!!!!!!!!!!!!!!!!!!!!!A0````_!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9"A!!'"G!!"BA9!!:A"A!'A!%!"M!$!!;Q$1!'D$M!"I06!!;!KQ!'A.5!"I#L!!;!V1!'A+M!"I$6!!:ALA!''.A!"A<A!!9"A!!(`````!!!%!0```````````````````````````````````````````Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!,GZ!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!,H2R=P2O1!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!,H2R<_`P\`,U<E!!!!!!!!!!!!!!!!!!!!!``]!!,H2R<_`P\_`P\_`S^'Z!!!!!!!!!!!!!!!!!!$``Q$,R<_`P\_`P\_`P\_`P]P2!!!!!!!!!!!!!!!!!0``!-8&P\_`P\_`P\_`P\_``]M!!!!!!!!!!!!!!!!!``]!R=P,R<_`P\_`P\_`````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]7`P\_````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P&U@```````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]P`````````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,S``````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P,`````````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]P`````````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,S``````````&!!!!!!!!!!!!!!!!!0``!-P,S]P,S]P,````````S]M!!!!!!!!!!!!!!!!!``]!!-8&S]P,S]P`````S^(&!!!!!!!!!!!!!!!!!!$``Q!!!!$&S]P,S```S]P&!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!R=P,S]O`!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!-7`!!!!!!!!!!!!!!!!!!!!!!!!!!$```````````````````````````````````````````]!!!!-!!&'5%B1!!!!!!!$!!!!"!!!!!!!!!*`!!!%[8C=L:2.;"."&-@@B+V-1IOTM<6>;5AMWVD%A#BK$8Y5/R5KJ3CRY#(5",>_1'MU(_+JP3R#$LU9T%(I,11]?1D&OQ1P?\!H"8O)$8DX5B4;T@JWUNV]&/0&82C7:8\P`_<^`QS!^)/.?"KQ;A*BO`AR:Y*0-QB!.5,BY!G`!L:!^I!-+M3%+<L!NDU.-GJ#PW;%[6G?BZ_YW`JOP99XB,!>X(K%+6D-:]*2T2C7<[EVJLY@6@.^4F5:!GS>.$TXV/!POK[H5"$U#8O6)[1"B*_5*(XM>P,JEK\;@\U2KIC38B-9.Q<3;OU56E4JD[)E791334EF!5N/1+63;5&S%QK,.C:NJI2F.]FC$]<0D5"'L:U2D%]QK,0J[0"AIW$X<E0>[$&O-%32?_E=O?2I];!Z*<B[P9Y=LA@=9R-'V>I.KN!>\6P@Q"X^!R!AV@P5_GK^MXFZXH:"\07D%?.2QG,Y(40BN'ZY%ERSN(*1%$:)DAV8<"NO#BO]0-_AZ50B(TZQK4I7G&\/:<*,[6$K9?D"=D+4#4V,0XG2T#[&N'1W?>CBK^R1TNOHN]6%/'!)*(A/C@:JJ["=,O-!='WBVR!>6GMO*YP4;/\%N><%<>87Z+\DZ0DPOY`M[9V(05ZGI:87=ZB7G85XV*(7#`]`L2=R2+N>;95YPCM^EH?J#<7F.9\5#M2\-*0)L(7E6;AY/LX3?PFQ7O//FJP79L(9Q?(-IWZ;*5+;;>7XL(VL(T/,YZ5A!1G27@$/NX6/NT`FX-O&RF2O5?8P'^A-CKW:--3H`:`:,&<LJ\.UBGWAKXA>(;=<>,@[R<V_KH-OK7^"D*R1XQ<JS"_4`W<E!!!!!!1!!!!A!!!!"!!!!!!!!!!-!!%B1!!!!!!!$!!!!"!!!!!!!!!"C!!!!=HC=9W"AS"/190L(50?8A5HA+Z!B`:?"7>#0]4=$![?@Q'%AT3AA#237`=P!,KA.&N9_IMP"!!7K<)Q=EBS("4H!-BQN'AT````H_(LE'FT&%2]Y5W770)=%!"2C'1!!!!!!!!1!!!!(!!!#"1!!!!=!!!!B8WZJ8URB=X2,<G^X<E^X<GFO:UR71WRB=X.$<(6T>'6S!!!!0C%!A!!!!!!"!!A!-0````]!!1!!!!!!)A!!!!%!'E"1!!!347FT=WFO:S"P<C"1=G^K:7.U!!!"!!!!!!!!!!!!'ER71WRB=X.1=GFW982F2'&U962B9E^S:'6S!!!!*3%!A!!!!!!#!!5!"Q!!$!"!!!(`````!!!!!1!"!!!!!!!!!!!!!!!<4&:$<'&T=V"S;8:B>'6%982B6'FN:8.U97VQ!!!!'3%!A!!!!!!"!!5!"Q!!!1!!WN1HY!!!!!!!!!!G4&:$<'&T=V"S;8:B>'6%982B4'&T>%&Q='RJ:725;7VF=X2B<8!!!!!:)1#!!!!!!!%!"1!(!!!"!!$;V#@A!!!!!!!!!"J-6E.M98.T5(*J>G&U:52B>'&5?8"F2'6T9Q!!!$YB!)!!!!!!!1!)!$$`````!!%!!!!!!#)!!!!"!"J!5!!!%EVJ=X.J<G=A<WYA5(*P;G6D>!!!!1!!!!!!!!!!!"Z-6E.M98.T5(*J>G&U:52B>'&%:GRU2'&U96.J?G5!!!!:)1#!!!!!!!%!"1!$!!!"!!!!!!!!!!!!!!!!!"2/33Z-6CZ"<'QO5W^V=G.F4WZM?1!!!"5B!)!!!!!!!1!%!#%!!1!!!1!!!!!!!!!!!!!%!!)!#!!!!!1!!!"!!!!!+!!!!!)!!!1!!!!!#A!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$H!!!":8C=D:".3A."%)7`G6;440S*#C+#U!N"6W[]Q%$!H4"Y!M@Z#3..2K9\Q;7(>/8++XA$8S92&\K1"U86K[LXKBMYZJ(0^\@,$S!_OWO]<_9TW]RNVL6062'OX<*QO@=H@\3+Y,B+-TC@OI5067@<WP<4^LFLFHGI<*G(H'W"B",-+:%+MSGZ54J+"ZD;T2CGL[;^$WOC;GMGUD9;XW&A&G6.MP)SY;85>E<-E"%8``+0[755)L4W)/MN<C6CW760Z!L\-PN'N-&PZK>TU'0^E)C*&.&"_E:F#7-//6)=@Q&=7TMH!!!!!'5!!1!#!!-!"!!!!%A!$Q1!!!!!$Q$:!.1!!!"2!!]%!!!!!!]!W1$5!!!!7A!0"!!!!!!0!.E!V!!!!'/!!)1!A!!!$Q$:!.1)5W6H<W5A65E)5W6H<W5A65E)5W6H<W5A65E"-!!!!&*45E-.#A!$4&:$1UR#6F=!!!\Y!!!%@Q!!!#!!!!\9!!!!!!!!!!!!!!!A!!!!.!!!"'A!!!!?4%F#4A!!!!!!!!&Y4&:45A!!!!!!!!'-5F242Q!!!!!!!!'A1U.46!!!!!!!!!'U4%FW;1!!!!!!!!()1U^/5!!!!!!!!!(=6%UY-!!!!!!!!!(Q2%:%5Q!!!!!!!!)%4%FE=Q!!!!!!!!)96EF$2!!!!!!!!!)M2U.%31!!!!!!!!*!>G6S=Q!!!!1!!!*55U.45A!!!!!!!!+Y2U.15A!!!!!!!!,-35.04A!!!!!!!!,A;7.M/!!!!!!!!!,U4%FG=!!!!!!!!!-)2F"&?!!!!!!!!!-=2F")9A!!!!!!!!-Q2F"421!!!!!!!!.%6F"%5!!!!!!!!!.94%FC:!!!!!!!!!.M1E2&?!!!!!!!!!/!1E2)9A!!!!!!!!/51E2421!!!!!!!!/I6EF55Q!!!!!!!!/]2&2)5!!!!!!!!!01466*2!!!!!!!!!0E3%F46!!!!!!!!!0Y6E.55!!!!!!!!!1-2F2"1A!!!!!!!!1A!!!!!0````]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!E!!!!!!!!!!$`````!!!!!!!!!-A!!!!!!!!!!0````]!!!!!!!!!X!!!!!!!!!!!`````Q!!!!!!!!$E!!!!!!!!!!$`````!!!!!!!!!2!!!!!!!!!!!0````]!!!!!!!!"'!!!!!!!!!!!`````Q!!!!!!!!&!!!!!!!!!!!$`````!!!!!!!!!9A!!!!!!!!!!0````]!!!!!!!!"G!!!!!!!!!!!`````Q!!!!!!!!,=!!!!!!!!!!4`````!!!!!!!!!P1!!!!!!!!!"`````]!!!!!!!!$#!!!!!!!!!!)`````Q!!!!!!!!-9!!!!!!!!!!H`````!!!!!!!!!SQ!!!!!!!!!#P````]!!!!!!!!$0!!!!!!!!!!!`````Q!!!!!!!!.1!!!!!!!!!!$`````!!!!!!!!!WA!!!!!!!!!!0````]!!!!!!!!$@!!!!!!!!!!!`````Q!!!!!!!!1!!!!!!!!!!!$`````!!!!!!!!#!1!!!!!!!!!!0````]!!!!!!!!)&!!!!!!!!!!!`````Q!!!!!!!!A=!!!!!!!!!!$`````!!!!!!!!#K!!!!!!!!!!!0````]!!!!!!!!+K!!!!!!!!!!!`````Q!!!!!!!!KQ!!!!!!!!!!$`````!!!!!!!!#M!!!!!!!!!!!0````]!!!!!!!!+S!!!!!!!!!!!`````Q!!!!!!!!MQ!!!!!!!!!!$`````!!!!!!!!#TA!!!!!!!!!!0````]!!!!!!!!.2!!!!!!!!!!!`````Q!!!!!!!!V-!!!!!!!!!!$`````!!!!!!!!$61!!!!!!!!!!0````]!!!!!!!!.A!!!!!!!!!#!`````Q!!!!!!!!ZM!!!!!":.;8.T;7ZH)'FO)&"S<WJF9X1O9X2M!!!!!!
+
+
+
+
+!!!!!2J.;8.T;7ZH)'FO)&"S<WJF9X1O<(:D<'&T=Q"16%AQ!!!!!!!!!!!!!!!$!!%!!!!!!!1"!!!!!1!;1&!!!"*5:7VQ<'&U:3"5:8.U)%.B=W5!!!%!!!!!!!(````_!!!!!!%84&6O;81A6'6T>#"$98.F,GRW9WRB=X.16%AQ!!!!!!!!!!!!)!#!!!!!!!!!!!!!!!!!!!%!!!!!!!!#!!!!!1!;1&!!!"*5:7VQ<'&U:3"5:8.U)%.B=W5!!!%!!!!!!!(````_!!!!!!%84&6O;81A6'6T>#"$98.F,GRW9WRB=X.16%AQ!!!!!!!!!!!!)1#!!!!!!!!!!!!!!!!!!!%!!!!!!!!!!!!!!1!;1&!!!"*5:7VQ<'&U:3"5:8.U)%.B=W5!!!%!!!!!!!(````_!!!!!!%84&6O;81A6'6T>#"$98.F,GRW9WRB=X.16%AQ!!!!!!!!!!!!)1#!!!!!!!!!!!!!!!)!!!!;6'6N='RB>'5A6'6T>#"$98.F,GRW9WRB=X-!!!!;47FT=WFO:S"P<C"1=G^K:7.U,GRW9WRB=X-
+
+
+
+
+ false
+ 1.0.0.0
+ 50 49 48 49 56 48 48 54 13 0 0 0 0 1 23 21 76 111 97 100 32 38 32 85 110 108 111 97 100 46 108 118 99 108 97 115 115 0 0 1 0 0 0 0 0 9 0 0 12 241 1 100 1 100 80 84 72 48 0 0 0 4 0 0 0 0 0 0 12 158 0 40 0 0 12 152 0 0 12 0 0 0 0 0 0 32 0 32 0 24 0 0 0 0 0 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 96 125 139 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 77 73 115 115 105 110 103 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11 83 109 97 108 108 32 70 111 110 116 115 0 1 8 1 1
+
+
+
-
+
+
+ -
+ 2
+
+ -
+ 2
+
-
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!$,!!!!#!!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!"B!=!!)!!!!8Q!!#UVZ)%.P<8"V>'6S!":!5!!$!!!!!1!##'6S=G^S)'FO!!"5!0!!$!!$!!1!"!!&!!1!"!!%!!1!"A!%!!1!"!-!!(A!!!U)!!!!!!!!!!!!!!E!!!!!!!!!!!!!!!!!!!!!!!!!#A!!!!!!!!!!!!!!!!!!!!!"!!=!!!!!
+ -1
+ 0
+ true
+ 2
+ 1
+ 1115685394
+
+
+ -
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!%3!!!!#!!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$2!=!!?!!!='EVJ=X.J<G=A;7YA5(*P;G6D>#ZM>G.M98.T!!!.6'6T>#"$98.F)%^V>!!U1(!!(A!!("J.;8.T;7ZH)'FO)&"S<WJF9X1O<(:D<'&T=Q!!$&2F=X1A1W&T:3"*<A!!91$Q!!Q!!Q!%!!1!"1!%!!1!"!!%!!1!"!!%!!9$!!"Y!!!*!!!!!!!!!!!!!!!.#Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")!!!U!!!!-!!!!!!!!!!!!!!%!"Q!!!!!
+ -1
+ 0
+ true
+ 1
+ 1
+ 1350574608
+
+ -
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!%3!!!!#!!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$2!=!!?!!!='EVJ=X.J<G=A;7YA5(*P;G6D>#ZM>G.M98.T!!!.6'6T>#"$98.F)%^V>!!U1(!!(A!!("J.;8.T;7ZH)'FO)&"S<WJF9X1O<(:D<'&T=Q!!$&2F=X1A1W&T:3"*<A!!91$Q!!Q!!Q!%!!1!"1!%!!1!"!!%!!1!"!!%!!9$!!"Y!!!*!!!!!!!!!!!!!!!.#Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")!!!U!!!!-!!!!!!!!!!!!!!%!"Q!!!!!
+ -1
+ 0
+ true
+ 1
+ 1
+ 1350574608
+
+ -
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!%3!!!!#!!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$2!=!!?!!!='EVJ=X.J<G=A;7YA5(*P;G6D>#ZM>G.M98.T!!!.6'6T>#"$98.F)%^V>!!U1(!!(A!!("J.;8.T;7ZH)'FO)&"S<WJF9X1O<(:D<'&T=Q!!$&2F=X1A1W&T:3"*<A!!91$Q!!Q!!Q!%!!1!"1!%!!1!"!!%!!1!"!!%!!9$!!"Y!!!*!!!!!!!!!!!!!!!.#Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")!!!U!!!!-!!!!!!!!!!!!!!%!"Q!!!!!
+ -1
+ 0
+ true
+ 1
+ 1
+ 1117782544
+
+
diff --git a/Tooling/Unit tests/Missing in Project/Test Missing Classes.vi b/Tooling/Unit tests/Missing in Project/Test Missing Classes.vi
new file mode 100644
index 00000000..0188a300
Binary files /dev/null and b/Tooling/Unit tests/Missing in Project/Test Missing Classes.vi differ
diff --git a/Tooling/Unit tests/Missing in Project/Test Missing Libraries.vi b/Tooling/Unit tests/Missing in Project/Test Missing Libraries.vi
new file mode 100644
index 00000000..ab6b4dfd
Binary files /dev/null and b/Tooling/Unit tests/Missing in Project/Test Missing Libraries.vi differ
diff --git a/Tooling/Unit tests/Missing in Project/Test Missing PPLs.vi b/Tooling/Unit tests/Missing in Project/Test Missing PPLs.vi
new file mode 100644
index 00000000..d1581fb3
Binary files /dev/null and b/Tooling/Unit tests/Missing in Project/Test Missing PPLs.vi differ
diff --git a/Tooling/Unit tests/Missing in Project/Test Missing VIs.vi b/Tooling/Unit tests/Missing in Project/Test Missing VIs.vi
new file mode 100644
index 00000000..7843c600
Binary files /dev/null and b/Tooling/Unit tests/Missing in Project/Test Missing VIs.vi differ
diff --git a/Tooling/Unit tests/Missing libraries on LV project.vi b/Tooling/Unit tests/Missing libraries on LV project.vi
deleted file mode 100644
index ea35ee7a..00000000
Binary files a/Tooling/Unit tests/Missing libraries on LV project.vi and /dev/null differ
diff --git a/Tooling/Unit tests/Text-Based VI Icon Tests/Test Split Text into Words.vi b/Tooling/Unit tests/Text-Based VI Icon Tests/Test Split Text into Words.vi
new file mode 100644
index 00000000..7aef598b
Binary files /dev/null and b/Tooling/Unit tests/Text-Based VI Icon Tests/Test Split Text into Words.vi differ
diff --git a/Tooling/Unit tests/Text-Based VI Icon Tests/Text-Based VI Icon Tests.lvclass b/Tooling/Unit tests/Text-Based VI Icon Tests/Text-Based VI Icon Tests.lvclass
new file mode 100644
index 00000000..ff04f32d
--- /dev/null
+++ b/Tooling/Unit tests/Text-Based VI Icon Tests/Text-Based VI Icon Tests.lvclass
@@ -0,0 +1,42 @@
+
+
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!)@!!!*Q(C=\>3R=?-Q%)8B>T=88+I/<N4#NK!7V-+WI.3B7HCR-\7A&L9&N;!7Y*`Q7K0RD-X!^JQ$EY*M0A+,4S#'UDT_3H]UVI\(>Y`V_[^,P,I;^]&Y[`Z90G0/.J\$U6@DZ6Z`(M@NOU=]^\LP]T+_+X\M^[X>8THU=`Q=``>Y7.WE8\ZH@WFZ%>'+:FL31MN5I]C,P-C,P-C,X/1G.\H*47\S*%`S*%`S*%`S)!`S)!`S)!`S?:+,8/1CBV2-8ER5&#U+&*WBK0AK0)7H]"1?,F6Y#E`B+4S&BSYK0)7H]"3?QM-Q&:\#5XA+4_'BV*450-HR&"\+SXC-RXC-RXC95M:D!'9S5^A5A3&TU`RD0-:D00QLYT%?YT%?Y_'WD->YD->YD)=B=V5].=N*DI=S3DS**`%EHM2$;37?R*.Y%E`C94IFHM34)*)*E_)1F!R+/C18C3@R]%?**`%EHM34?,AVHV$/F6EUSUG/*`!%HM!4?!)0*22Y!E`A#4S"B\)+0)%H]!3?Q-.5#DS"*`!%E'"3JF>1,"A9>!K#Q-.H\J;94]F4%P/5?P/K.[6[M[EXE8JTK"_[_G'K(Z*[]>7,KFYM^3+I@ZQ;L=;I*V%08DLKSP?&>K;>;%@;A<;H\7B<WG9:_ME>L^?L,J?,TO?T4K?4DM?D$I?$^PO^>LO>NNON.JP.\48QD`0W1PA/\[6P9@CN_\KMU2-:RRC"!!!!!!
+ 553680896
+ 1.0.0.0
+ true
+ true
+ true
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!"/V5F.31QU+!!.-6E.$4%*76Q!!$R!!!!3F!!!!)!!!$P!!!!!F!!!!!3"5:8BU,5*B=W6E)&:*)%FD<WYA6'6T>(-O<(:D<'&T=Q!!!!!!!+!B!)!!!$!!!#A!"!!!!!!%!!-!0!#]!"^!A!)!!!!!!1!"!!<`````!!!!!!!!!!!!!!!!@L9IB-*)C%/V@^`A$<]S?Q!!!!Q!!!!1!!!!!(..A.F4VD>'H7EOWTEU%IH5(9T:DQ#S"/G!#:DM_%*_!!!!!!!!!!!_+.*0=EOH1;"TY@H__BE]!1!!!0`````5(9T:DQ#S"/G!#:DM_%*_!!!!%/>D#.#,@KEB8.<;+N&E8'E!!!!%!!!!!!!!!#=!!5R71U-!!!!"!!*735R#!!!!!&"53$!!!!!&!!%!!1!!!!!#!!-!!!!!!A!"!!!!!!!C!!!!'HC=9W"D9'JAO-!!R)R!T.4!^!0)`M$!Q!!!6J5'ZA!!!!!!1Q!!!2BYH'.AQ!4`A1")-4)QM)#Y,'DC9"L'JC<!:3YOO[$CT&!XME*%'9&CT#_!$#;1(+J?&A9E\]!"'R;T!96Q*@!!!!!!$!!"6EF%5Q!!!!!!!Q!!!4]!!!-A?*Q,9'2A++]Q-R&A9G"A"L)6'2I9EP.45LE9A(Q'"0D$R%!2;)#;JY5G<HDA="I1[0(,NY$Z(MVP.$S<@T#6#HLMA+HZ@]'D_9D'99`O2J$1=9=%M-*O2M.,LI9(`E_Y!.9'6-!P\Q$7XV"JT6$#<HA!,(C]]1MDR"A-!U(K>Y!E$[0;\X(Q%9MH8,&8,QO46\))EU?H#Z@"=2?O!$'1MFY2,KTGB1%.50$I0)?1X-5)5>(.BR$T[(1-1/&J)0-;,[#Y&CDQ!6XA!=40#H'(#15]C7$N[XO\10(%BC4GQ!#*0Q9G6+T(Q-A!]BS)T)7KN1'SG;"C-F!R%(MPF+W"J/=7EPEQM6FA.2$\7+&C\["]%0M0E![!MLG!GC:!W>*!NA#5L1.E8Y#Z&Q`N\/`CSI!F83/H>1"/FWD?!!!!!"-!!!!*?*RD9'"A:'1!!A!!&!!$!!!!!!YB!9!'!!!'-D%O-#YR!!!!!!!!$#%!A!!!!!1S-3YQ!!!!!!YB!9!'!!!'-D%O-#YR!!!!!!!!$#%!A!!!!!1S-3YQ!!!!!!YB!9!'!!!'-D%O-#YR!!!!!!!!&!%!!!$V6T7#?3;CD#ZT5EY'34G>!!!!$1!!!!!!!!!!!!!!!!!!!!!!!!#!`````Y!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A'!!!9'9!!''"A!"G!'!!;!!1!'Q!-!"L!.!!;-/Q!'A^5!"I#L!!;!V1!'A+M!"I$6!!;!KQ!'A.5!"G#O!!99W!!'"O!!"A'!!!@````]!!!1!````````````````````````````````````````````!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!O<E!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!O>(&S^'Z!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!O>(&P\_`P]P2O1!!!!!!!!!!!!!!!!!!!!$``Q!!O>(&P\_`P\_`P\`,U<E!!!!!!!!!!!!!!!!!!0``!-P&P\_`P\_`P\_`P\_`S^%!!!!!!!!!!!!!!!!!``]!R=7`P\_`P\_`P\_`P\``SQ!!!!!!!!!!!!!!!!$``Q$&S]P&P\_`P\_`P\`````&!!!!!!!!!!!!!!!!!0``!-8,S]P,R<_`P\```````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]82````````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,S``````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P,`````````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]P`````````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,S``````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P,`````````]5!!!!!!!!!!!!!!!!!``]!S]P,S]P,S]P````````,SQ!!!!!!!!!!!!!!!!$``Q!!R=8,S]P,S``````,U=5!!!!!!!!!!!!!!!!!!0``!!!!!-8,S]P,```,S]5!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!$&S]P,S\]!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!R<]!!!!!!!!!!!!!!!!!!!!!!!!!!0```````````````````````````````````````````Q!!!!)!!1!!!!!!$!!"2F")5!!!!!!!!Q!!!!1!!!!!!!!#@Q!!"/FYH+W547A4124(XY3N4%+,M\'V87F),.N9R)!I;AV_&$M6+K5IM?!BV!3X@E"L."`CK<UM1A[^'-R"[#U%0(E)R<M%,XOQ*Q6\C!VY^V)5WMX[>N,>@"4DR6U9FG6_\``G`@]-A03$D8A;M'I#9<PY-7?#4T-)1$6#Y?!*PQ+W10;!$#L%B#G[Q,9^$4*K1L^GB/F:HI?@O.P[<LW'.Y3Q(>R[B#F9T'@#5=U9FG_J.;;_(V8T@5Z6'1*MH41]^^4A,\KOJV!1^!F\F3/E!93@F#2^\(<S[:+OWH_^%;K)EFY4'$='UGLN&&:%[9_C*&G%%EEZ*1&,4E#F5GF"=B-+CT9G<;;%:4@*9A`'TYV!2KW>%9R0-+CT[?DQ9+.A^WZ$X?AR<D"%E8PJ(,HE;0'A/37Y?LW/(+Y(X'-4"N8;$;L1(?V<X]!>`1-1).8\V0JKP<.Z?>ZW1?TVIR(D5=*C_"UTY<2O?"*-=L2S5"!W3)Y.6WQ<<AI<P$T0I/6$Y2]_=+E[&JB?TG7S3_F1[G(IQ8)SEQE^3T^ZE=QOB<2E.HH9I;P=5-\<J\@&2$BA##2Y$IHW;;?A8#\D!("NI>=1(6:L,C?,UWDOR,87R'X6VO3OY_4Y\\O0\/G.2TV/:K'6VH/96JFV.^32VAP`0[U8-53L87G&/,YL0:*XK1GVJ47/V!L%?T#4S+RVJ&7I/$K^UHLZ=&LDDJ;<VG+RW-(BT+.O7C6#GGH6N[R^;R]TC_/6)!%*E6HQTL>V4L=`Z>T,B=:5<F(F\RP9$)KNG4$%J`W@W3R7[[?T>):NI+NY(2WH'X3X_M7^@KJT,KFP19S=5.]'[=A@E`^GZ!!!!!!%!!!!)!!!!!1!!!!!!!!!$!!"1E2)5!!!!!!!!Q!!!!1!!!!!!!!!9A!!!(*YH'.A9-A4E'$[RV$XFY&*Y#O1)@W8A6H1D`%X!Q/HH]"B)-UI)!E5FPX,Q#[I$2<70K,,Q1!&KGS-(*)=BQ5ZQ$)=,2I-````Z`B[Z"J=R2%@/&.FFDS("!!59BE!!!!!!!!%!!!!"Q!!!AM!!!!(!!!!)6^O;6^-98.U3WZP>WZ0>WZJ<G>-6E.M98.T1WRV=X2F=A!!!%1B!)!!!!!!!1!)!$$`````!!%!!!!!!#A!!!!"!#"!5!!!'&2F?(1N1G&T:71A6EEA37.P<C"5:8.U=Q!!!1!!!!!!!!!!!"2/33Z-6CZ"<'QO5W^V=G.F4WZM?1!!!"5B!)!!!!!!!1!%!#%!!1!!!1!!!!!!!!!;4&:$<'&T=V"S;8:B>'6%982B6'&C4X*E:8)!!!!F)1#!!!!!!!)!"1!(!!!-!%!!!@````]!!!!"!!%!!!!!!!!!!!!!!"N-6E.M98.T5(*J>G&U:52B>'&5;7VF=X2B<8!!!!!:)1#!!!!!!!%!"1!(!!!"!!$;V#@A!!!!!!!!!#:-6E.M98.T5(*J>G&U:52B>'&-98.U18"Q<'FF:&2J<76T>'&N=!!!!"EB!)!!!!!!!1!&!!=!!!%!!.L5*_!!!!!!!!!!'ER71WRB=X.1=GFW982F2'&U962Z='6%:8.D!!!!0C%!A!!!!!!"!!A!-0````]!!1!!!!!!)A!!!!%!'E"1!!!36'6Y>#V#98.F:#"733"*9W^O!!!"!!!!!!!!!!!!(ER71WRB=X.1=GFW982F2'&U952G<(2%982B5WF[:1!!!"EB!)!!!!!!!1!&!!-!!!%!!!!!!!!!!!!!!!!!!!1!!A!)!!!!"!!!!%!!!!!I!!!!!A!!"!!!!!!+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!/M!!!&R?*S.E-&+!T%52=^-V,:4N65X864)IK!<X@A$AU+BOS,CWD$*F%,IF#9N8@K2LFTZ#`["L^.+&U71#Y`X<N[^.QFQR9TPTY_<,S$6,WY>\RZ.=&;`DP3IK':#B2DO`;LQ*I4_HQN&^.TG9\B_]MM1X5*8J;YV?L[9LERUWJJI/";195(V3'21OZ%(;6NZ!V8[#=X]8680=5OYKK1LXEL74WCIJ3X*.FEKLKWIR[1U;4(Y6XZ+<3-F172P%HX%5%QUJZQ*O='ZB0UCW?'1W:^U;GQ@EN!62_2#]K83:<3ZY&*K_Q@I`TZ(!!!!!'5!!1!#!!-!"!!!!%A!$Q1!!!!!$Q$:!.1!!!"2!!]%!!!!!!]!W1$5!!!!7A!0"!!!!!!0!.E!V!!!!'/!!)1!A!!!$Q$:!.1)5W6H<W5A65E)5W6H<W5A65E)5W6H<W5A65E"-!!!!&*45E-.#A!$4&:$1UR#6F=!!!]1!!!%J1!!!#!!!!\Q!!!!!!!!!!!!!!!A!!!!.!!!")A!!!!@4%F#4A!!!!!!!!'%4&:45A!!!!!!!!'95F242Q!!!!!!!!'M1U.46!!!!!!!!!(!4%FW;1!!!!!!!!(51U^/5!!!!!!!!!(I6%UY-!!!!!!!!!(]2%:%5Q!!!!!!!!)14%FE=Q!!!!!!!!)E6EF$2!!!!!!!!!)Y2U.%31!!!!!!!!*->G6S=Q!!!!1!!!*A5U.45A!!!!!!!!,%2U.15A!!!!!!!!,935.04A!!!!!!!!,M;7.M/!!!!!!!!!-!1V"$-A!!!!!!!!-54%FG=!!!!!!!!!-I2F"&?!!!!!!!!!-]2F")9A!!!!!!!!.12F"421!!!!!!!!.E6F"%5!!!!!!!!!.Y4%FC:!!!!!!!!!/-1E2&?!!!!!!!!!/A1E2)9A!!!!!!!!/U1E2421!!!!!!!!0)6EF55Q!!!!!!!!0=2&2)5!!!!!!!!!0Q466*2!!!!!!!!!1%3%F46!!!!!!!!!196E.55!!!!!!!!!1M2F2"1A!!!!!!!!2!!!!!!0````]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!M!!!!!!!!!!$`````!!!!!!!!!.!!!!!!!!!!!0````]!!!!!!!!!Z!!!!!!!!!!!`````Q!!!!!!!!$M!!!!!!!!!!$`````!!!!!!!!!2A!!!!!!!!!!0````]!!!!!!!!")!!!!!!!!!!!`````Q!!!!!!!!&)!!!!!!!!!!$`````!!!!!!!!!:!!!!!!!!!!!0````]!!!!!!!!"I!!!!!!!!!!!`````Q!!!!!!!!,E!!!!!!!!!!4`````!!!!!!!!!PQ!!!!!!!!!"`````]!!!!!!!!$%!!!!!!!!!!)`````Q!!!!!!!!-A!!!!!!!!!!H`````!!!!!!!!!T1!!!!!!!!!#P````]!!!!!!!!$2!!!!!!!!!!!`````Q!!!!!!!!.9!!!!!!!!!!$`````!!!!!!!!!X!!!!!!!!!!!0````]!!!!!!!!$B!!!!!!!!!!!`````Q!!!!!!!!1)!!!!!!!!!!$`````!!!!!!!!#!Q!!!!!!!!!!0````]!!!!!!!!)&!!!!!!!!!!!`````Q!!!!!!!!AE!!!!!!!!!!$`````!!!!!!!!##Q!!!!!!!!!!0````]!!!!!!!!+M!!!!!!!!!!!`````Q!!!!!!!!KY!!!!!!!!!!$`````!!!!!!!!#M!!!!!!!!!!!0````]!!!!!!!!+U!!!!!!!!!!!`````Q!!!!!!!!L9!!!!!!!!!!$`````!!!!!!!!#U!!!!!!!!!!!0````]!!!!!!!!,3!!!!!!!!!!!`````Q!!!!!!!!V9!!!!!!!!!!$`````!!!!!!!!$7!!!!!!!!!!!0````]!!!!!!!!.;!!!!!!!!!!!`````Q!!!!!!!!W5!!!!!!!!!)$`````!!!!!!!!$I1!!!!!(&2F?(1N1G&T:71A6EEA37.P<C"5:8.U=SZD>'Q!!!!!
+
+
+
+
+!!!!!3"5:8BU,5*B=W6E)&:*)%FD<WYA6'6T>(-O<(:D<'&T=Q"16%AQ!!!!!!!!!!!!!!!!!!-!!1!!!!!!"!%!!!!"!"J!5!!!%F2F<8"M982F)&2F=X1A1W&T:1!!!1!!!!!!!@````Y!!!!!!2>-67ZJ>#"5:8.U)%.B=W5O<(:D<'&T=V"53$!!!!!!!!!!!!!A!)!!!!!!!!!!!!!!!!!!!1!!!!!!!!)!!!!"!"J!5!!!%F2F<8"M982F)&2F=X1A1W&T:1!!!1!!!!!!!@````Y!!!!!!2>-67ZJ>#"5:8.U)%.B=W5O<(:D<'&T=V"53$!!!!!!!!!!!!!B!)!!!!!!!!!!!!!!!!!!!1!!!!!!!!!!!!!"!"J!5!!!%F2F<8"M982F)&2F=X1A1W&T:1!!!1!!!!!!!@````Y!!!!!!2>-67ZJ>#"5:8.U)%.B=W5O<(:D<'&T=V"53$!!!!!!!!!!!!!B!)!!!!!!!!!!!!!!!A!!!"J5:7VQ<'&U:3"5:8.U)%.B=W5O<(:D<'&T=Q!!!"J5:8BU,5*B=W6E)&:*)%FD<WYO<(:D<'&T=Q
+
+
+
+
+ false
+ 1.0.0.0
+ 50 49 48 49 56 48 48 54 13 0 0 0 0 1 23 21 76 111 97 100 32 38 32 85 110 108 111 97 100 46 108 118 99 108 97 115 115 0 0 1 0 0 0 0 0 9 0 0 12 243 1 100 1 100 80 84 72 48 0 0 0 4 0 0 0 0 0 0 12 158 0 40 0 0 12 152 0 0 12 0 0 0 0 0 0 32 0 32 0 24 0 0 0 0 0 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 63 81 181 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 84 101 120 116 32 73 99 111 110 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11 83 109 97 108 108 32 70 111 110 116 115 0 1 8 1 0
+
+
+ -
+
+
+ -
+ 2
+
+ -
+ 2
+
+ -
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!%?!!!!#!!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$J!=!!?!!!C)&2F?(1N1G&T:71A6EEA37.P<C"5:8.U=SZM>G.M98.T!!!.6'6T>#"$98.F)%^V>!![1(!!(A!!)C"5:8BU,5*B=W6E)&:*)%FD<WYA6'6T>(-O<(:D<'&T=Q!!$&2F=X1A1W&T:3"*<A!!91$Q!!Q!!Q!%!!1!"1!%!!1!"!!%!!1!"!!%!!9$!!"Y!!!*!!!!!!!!!!!!!!!*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"!!!!U!!!!-!!!!!!!!!!!!!!%!"Q!!!!!
+ -1
+ 0
+ true
+ 1
+ 1
+ 1342972432
+
+
diff --git a/Tooling/Unit tests/Text-Based VI Icon/Split Text into Words.vi b/Tooling/Unit tests/Text-Based VI Icon/Split Text into Words.vi
deleted file mode 100644
index f54b898b..00000000
Binary files a/Tooling/Unit tests/Text-Based VI Icon/Split Text into Words.vi and /dev/null differ
diff --git a/Tooling/Unit tests/Text-Based VI Icon/Test Caller.vi b/Tooling/Unit tests/Text-Based VI Icon/Test Caller.vi
deleted file mode 100644
index e9c0f5db..00000000
Binary files a/Tooling/Unit tests/Text-Based VI Icon/Test Caller.vi and /dev/null differ
diff --git a/Tooling/Unit tests/Text-Based VI Icon/Text-Based VI Icon Unit Tests.lvlib b/Tooling/Unit tests/Text-Based VI Icon/Text-Based VI Icon Unit Tests.lvlib
deleted file mode 100644
index 1f98c9b0..00000000
--- a/Tooling/Unit tests/Text-Based VI Icon/Text-Based VI Icon Unit Tests.lvlib
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
- )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!)S!!!*Q(C=\>5R5A)R&-<R$]?#FB0A=)6X";\!&>Y6M+4=+\T/SH(W#B3W&O]+8)(;4P]*4]='>M;2U=+%)(T**D_SG68K:3\>[GWKX&]M^&]=W`L\9EP;W@\FMLX/^C_L@L>`;P[0=K:`YP>>,*0<K``S8X[X\#90[>80\%TN152,7N#=:GJ,P36ZEC>ZEC>ZEA>ZE!>ZE!>ZE$OZETOZETOZEROZE2OZE2OZE@>+,H+2CRR3MHCS5$*J-E%S')K3N]34?"*0YO'L%E`C34S**`%Q2)EH]33?R*.YO%S**`%EHM34?*CK3\*8=DS*B_E6?!*0Y!E]A9=F&8A#1,"9-(%Q#1Q&H='(Q".Y!A]@&8A#4_!*0)'(<A7?Q".Y!E`AY:+_+^%VL:,D92IZ(M@D?"S0YW&K/2\(YXA=D_.B/4E?R_-AH!7>S3()O=A:Y(RR0)[(0X)]DM@R/"\(1V?`1^ZXJGF;*=>D?!S0Y4%]BI=J:(A-D_%R0);(;76Y$)`B-4S'B[6E?!S0Y4%ARK)M,W-SYU*DE"%9(F\^N&C`3^%FVKN5BV>V+&7(487)6)>$>>.6.V.VEV3<L^J5V7;J.E(VYV2I&5;VC/LC.F"(XA_U07WE$<1N<5.<UV;U2<PUBQ=?DU=>$A@N^XO.Y[BB',4><L8:<,2?L\6;L<29,$Y@!X@5TQ@#[<GUY`0TKW90AW;0,ZK.4[@70D`-4XVNT*8_F`[":[.O^(6?^OA>!#3U)Q!!!!!
- 1.0.0.0
- true
- 3
- 50 52 51 50 56 48 48 50 13 0 0 0 0 1 23 21 76 111 97 100 32 38 32 85 110 108 111 97 100 46 108 118 99 108 97 115 115 0 0 1 0 0 0 0 0 9 0 0 38 205 1 100 1 100 80 84 72 48 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 15 13 76 97 121 101 114 46 108 118 99 108 97 115 115 0 0 1 0 0 0 0 0 7 0 0 12 178 0 0 0 0 0 0 0 0 0 0 12 158 0 40 0 0 12 152 0 0 12 0 0 0 0 0 0 32 0 32 0 24 0 0 0 0 0 255 255 255 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 218 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 218 255 0 218 255 255 255 255 0 218 255 0 218 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 218 255 255 255 255 0 218 255 255 255 255 0 218 255 255 255 255 0 218 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 218 255 255 255 255 0 218 255 255 255 255 0 218 255 255 255 255 0 218 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 218 255 0 218 255 255 255 255 0 218 255 0 218 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 128 0 0 6 192 0 0 10 160 0 0 10 160 0 0 6 192 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 100 1 0 2 0 0 0 1 15 13 76 97 121 101 114 46 108 118 99 108 97 115 115 0 0 1 0 0 0 0 0 7 0 0 12 182 0 0 0 0 0 0 0 0 0 0 12 158 0 40 0 0 12 152 0 0 12 0 0 0 0 0 0 32 0 32 0 24 0 0 0 0 0 255 255 255 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 63 248 0 0 63 248 0 0 63 248 0 0 63 248 0 0 63 248 0 0 63 248 0 0 63 248 0 0 63 248 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 70 105 108 108 100 1 0 2 0 0 0 1 15 13 76 97 121 101 114 46 108 118 99 108 97 115 115 0 0 1 0 0 0 0 0 7 0 0 12 185 0 0 0 0 0 0 0 0 0 0 12 158 0 40 0 0 12 152 0 0 12 0 0 0 0 0 0 32 0 32 0 24 0 0 0 0 0 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 102 153 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 86 73 32 73 99 111 110 100 1 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11 83 109 97 108 108 32 70 111 110 116 115 0 1 8 1 1
-
-
-
-
-
diff --git a/Tooling/deployment/ApplyVIPC.vi b/Tooling/deployment/ApplyVIPC.vi
index 865c800c..f927afc7 100644
Binary files a/Tooling/deployment/ApplyVIPC.vi and b/Tooling/deployment/ApplyVIPC.vi differ
diff --git a/Tooling/deployment/BuildVIP.vi b/Tooling/deployment/BuildVIP.vi
deleted file mode 100644
index 77477b03..00000000
Binary files a/Tooling/deployment/BuildVIP.vi and /dev/null differ
diff --git a/Tooling/deployment/Dependencies.vipc b/Tooling/deployment/Dependencies.vipc
index e00ef392..e34006ac 100644
Binary files a/Tooling/deployment/Dependencies.vipc and b/Tooling/deployment/Dependencies.vipc differ
diff --git a/Tooling/deployment/Modify_VIPB_Display_Information.vi b/Tooling/deployment/Modify_VIPB_Display_Information.vi
new file mode 100644
index 00000000..d172cf87
Binary files /dev/null and b/Tooling/deployment/Modify_VIPB_Display_Information.vi differ
diff --git a/Tooling/deployment/Modify_VIPB_LabVIEW_Version.vi b/Tooling/deployment/Modify_VIPB_LabVIEW_Version.vi
deleted file mode 100644
index 6ff0700f..00000000
Binary files a/Tooling/deployment/Modify_VIPB_LabVIEW_Version.vi and /dev/null differ
diff --git a/Tooling/deployment/NI Icon editor.vipb b/Tooling/deployment/NI Icon editor.vipb
index adf31300..03fb571c 100644
--- a/Tooling/deployment/NI Icon editor.vipb
+++ b/Tooling/deployment/NI Icon editor.vipb
@@ -1,7 +1,7 @@
-
+
NI_Icon_editor
- 0.0.0.125
+ 21.0.0.12
false
..\..
..\..\builds\VI Package
@@ -16,7 +16,12 @@
LabVIEW
-
+
+ oglib_array >=6.0.1.20
+ oglib_error >=6.0.0.26
+ oglib_file >=6.0.2.28
+ oglib_lvzip >=5.0.9
+
@@ -97,7 +102,7 @@
LVAddons
false
false
- <OS Application Files>\NI\LVAddons\niiconeditor32
+ <OS Application Files>\NI\LVAddons\niiconeditor64
Install artifacts
@@ -138,22 +143,22 @@
2
- resource/plugins/lv_icon_x86.lvlibp
+ resource/plugins
0
true
- 3
+ 1
- resource/plugins/lv_icon_x64.lvlibp
+ resource/plugins/lv_icon_x86.lvlibp
0
true
3
- resource/plugins
+ resource/plugins/lv_icon_x64.lvlibp
0
true
- 1
+ 3
.
@@ -189,9 +194,6 @@
.gitignore
-
- azure-pipelines.yml
-
CODE_OF_CONDUCT.md
@@ -297,6 +299,22 @@
Tooling/RestoreSetupLVSource.vi
+
+ docs
+ .vscode
+
+
+ GOVERNANCE.md
+ docs
+
+
+ requirements.txt
+ Tooling/vs-code
+
+
+ Tooling/deployment/Modify_VIPB_Display_Information.vi
+ Tooling/deployment/release_notes.md
+
.
diff --git a/Tooling/deployment/VIP_Post-Install Custom Action.vi b/Tooling/deployment/VIP_Post-Install Custom Action.vi
index f14e23d7..92846c15 100644
Binary files a/Tooling/deployment/VIP_Post-Install Custom Action.vi and b/Tooling/deployment/VIP_Post-Install Custom Action.vi differ
diff --git a/Tooling/deployment/VIP_Post-Uninstall Custom Action.vi b/Tooling/deployment/VIP_Post-Uninstall Custom Action.vi
index 8be9b8ae..13efad44 100644
Binary files a/Tooling/deployment/VIP_Post-Uninstall Custom Action.vi and b/Tooling/deployment/VIP_Post-Uninstall Custom Action.vi differ
diff --git a/Tooling/deployment/VIP_Pre-Install Custom Action.vi b/Tooling/deployment/VIP_Pre-Install Custom Action.vi
index 682c0922..7f344d48 100644
Binary files a/Tooling/deployment/VIP_Pre-Install Custom Action.vi and b/Tooling/deployment/VIP_Pre-Install Custom Action.vi differ
diff --git a/Tooling/deployment/VIP_Pre-Uninstall Custom Action.vi b/Tooling/deployment/VIP_Pre-Uninstall Custom Action.vi
index 0d6c9be4..9e9fb94f 100644
Binary files a/Tooling/deployment/VIP_Pre-Uninstall Custom Action.vi and b/Tooling/deployment/VIP_Pre-Uninstall Custom Action.vi differ
diff --git a/Tooling/deployment/lv_icon_versions/lv_icon_uninstall_backup.zip b/Tooling/deployment/lv_icon_versions/lv_icon_uninstall_backup.zip
index 3fbf7e34..61728359 100644
Binary files a/Tooling/deployment/lv_icon_versions/lv_icon_uninstall_backup.zip and b/Tooling/deployment/lv_icon_versions/lv_icon_uninstall_backup.zip differ
diff --git a/Tooling/deployment/runner_dependencies.vipc b/Tooling/deployment/runner_dependencies.vipc
new file mode 100644
index 00000000..fd12b11b
Binary files /dev/null and b/Tooling/deployment/runner_dependencies.vipc differ
diff --git a/Tooling/support/Get Paths to Icon Editor Files in LV Installation.vi b/Tooling/support/Get Paths to Icon Editor Files in LV Installation.vi
index 554cb53b..51ff85a3 100644
Binary files a/Tooling/support/Get Paths to Icon Editor Files in LV Installation.vi and b/Tooling/support/Get Paths to Icon Editor Files in LV Installation.vi differ
diff --git a/azure-pipelines.yml b/azure-pipelines.yml
deleted file mode 100644
index b5a8e077..00000000
--- a/azure-pipelines.yml
+++ /dev/null
@@ -1,46 +0,0 @@
-# Removed trigger so pipeline runs only when requested via API
-# trigger:
-# branches:
-# include:
-# - main
-# - develop
-
-name: $(Build.BuildID)
-
-pool:
- name: "Default"
- demands: "iconeditor -equals true"
-
-variables:
- build_id: $(Build.BuildID)
- build_revision: $[counter('buildCounter',1)]
- build_version: '1.0.$(Build.BuildID).$(build_revision)'
- RelativePath: '$(Build.SourcesDirectory)'
- RelativePathScripts: '$(Build.SourcesDirectory)\pipeline\scripts'
-
-stages:
-- stage: BuildAndTest
- displayName: Build and Test LabVIEW Project
- jobs:
- - job: ExecuteScripts
- displayName: Execute Scripts
- steps:
- - task: PowerShell@2
- displayName: 'Set agent into development mode'
- inputs:
- filePath: '$(RelativePathScripts)\Set_Development_Mode.ps1'
- arguments: '-RelativePath "$(RelativePath)"'
- workingDirectory: '$(RelativePathScripts)'
- failOnStderr: true
- errorActionPreference: 'Stop'
-
- - task: PowerShell@2
- displayName: 'Test and Build the Icon Editor'
- inputs:
- filePath: '$(RelativePathScripts)\Build.ps1'
- arguments: >
- -RelativePath "$(RelativePath)"
- -AbsolutePathScripts "$(RelativePathScripts)"
- workingDirectory: '$(RelativePathScripts)'
- failOnStderr: true
- errorActionPreference: 'Stop'
\ No newline at end of file
diff --git a/docs/actions/build-vi-package.md b/docs/actions/build-vi-package.md
new file mode 100644
index 00000000..8cd09fae
--- /dev/null
+++ b/docs/actions/build-vi-package.md
@@ -0,0 +1,266 @@
+# **Documentation: Build VI Package & Release Workflow (Fork-Friendly)**
+
+This document describes a **complete guide** to setting up and using the “Build VI Package” GitHub Actions workflow in your repository—whether it's the original (`ni/labview-icon-editor`) or a **fork**. It explains each part of the workflow, including **how to configure it**, **why certain design choices were made**, and **what steps** you must follow to replicate this functionality on your own fork.
+
+---
+
+## **Table of Contents**
+
+1. [Overview](#overview)
+2. [Why Use This Workflow?](#why-use-this-workflow)
+3. [Core Features](#core-features)
+ - [1. Automatic Versioning](#1-automatic-versioning)
+ - [2. GPG Signing Toggle](#2-gpg-signing-toggle)
+ - [3. Artifact Build & Release](#3-artifact-build--release)
+ - [4. Custom Branding Via Metadata](#4-custom-branding-via-metadata)
+4. [Setting Up in Your Fork](#setting-up-in-your-fork)
+ - [1. Copy the Workflow File](#1-copy-the-workflow-file)
+ - [2. Update the Repository Check](#2-update-the-repository-check)
+ - [3. Ensure Runner & Permissions](#3-ensure-runner--permissions)
+5. [Workflow Behavior](#workflow-behavior)
+ - [Events That Trigger It](#events-that-trigger-it)
+ - [Label-Based Semver Bumps](#label-based-semver-bumps)
+ - [Release Candidate Logic](#release-candidate-logic)
+6. [Usage Examples](#usage-examples)
+ - [Pull Requests with Labels](#pull-requests-with-labels)
+ - [Direct Push to Main or Develop](#direct-push-to-main-or-develop)
+ - [Working on a Release Branch](#working-on-a-release-branch)
+7. [Detailed Step Explanations](#detailed-step-explanations)
+ - [Disable GPG Signing (if Fork)](#disable-gpg-signing-if-fork)
+ - [Compute Version](#compute-version)
+ - [Create Tag & Push](#create-tag--push)
+ - [Build the Icon Editor VI Package](#build-the-icon-editor-vi-package)
+ - [Upload Artifact](#upload-artifact)
+ - [Create GitHub Release](#create-github-release)
+ - [Re-Enable GPG Signing](#re-enable-gpg-signing)
+8. [Testing & Verification](#testing--verification)
+ - [Fork Testing](#fork-testing)
+ - [Main Repo Testing](#main-repo-testing)
+ - [Pull Request Testing](#pull-request-testing)
+9. [Troubleshooting](#troubleshooting)
+10. [FAQ](#faq)
+11. [Conclusion](#conclusion)
+
+---
+
+## **1. Overview**
+
+**Purpose**: This workflow provides a **consistent, automated release process** for LabVIEW Icon Editor packages, including:
+
+- Automatic **Semantic Version** bumping (major/minor/patch).
+- **Build** and **packaging** of the `.vip` artifact.
+- **Tag creation** in Git with a `vX.Y.Z-buildN` format.
+- **GitHub Release** creation, optionally as a pre-release if using a `release/*` branch.
+- **Flexible metadata branding** of the final package (repo name, organization, etc.).
+
+For **forks**, the workflow automatically **disables** GPG signing to avoid passphrase prompts.
+
+---
+
+## **2. Why Use This Workflow?**
+
+1. **Standardizes versioning**: Eliminates confusion about version increments; labels guide the semver bump.
+2. **Fork-friendly**: Fork owners won’t be blocked by GPG passphrase issues.
+3. **Reduces manual overhead**: No more ad-hoc tagging, manual artifact uploads, or drafting releases.
+4. **Encourages best practices**: Integrates cleanly with GitHub’s PR and branching model.
+5. **Unique package branding**: Inject repository/organization names to differentiate builds (especially valuable in multi-team or open-source contexts).
+
+---
+
+## **3. Core Features**
+
+### **1. Automatic Versioning**
+- Pull request labels (`major`, `minor`, `patch`) decide how much to increment the version.
+- Defaults to a `patch` bump if there’s no label or on direct pushes.
+
+### **2. GPG Signing Toggle**
+- If the repository name **is** `ni/labview-icon-editor`, signing stays enabled.
+- If **not**, the workflow disables signing, preventing passphrase prompts that occur when no keys are available on the fork’s runner.
+- Restores any prior Git config after the build completes.
+
+### **3. Artifact Build & Release**
+- Runs a PowerShell script (`Build.ps1`) to compile a `.vip` file.
+- Uploads the `.vip` to GitHub as a build artifact.
+- **Creates a release** in GitHub if it’s not a pull request, attaching the `.vip`.
+
+### **4. Custom Branding Via Metadata**
+- You can **pass metadata fields** (e.g., your **organization** or **repo name**) into the build script.
+- This branding data is injected into the final `.vip` package to uniquely identify **who** built it and **where** it originated.
+- Especially helpful if multiple forks or organizations produce their own builds and need a clear way to distinguish them.
+
+---
+
+## **4. Setting Up in Your Fork**
+
+### **1. Copy the Workflow File**
+- In your fork, create a new file:
+ `.github/workflows/build-vi-package.yml`
+- Copy the entire workflow YAML from the main repo or from a PR that merges these changes.
+- Commit it to your fork’s branch (e.g., `develop`).
+
+### **2. Update the Repository Check**
+- Locate lines like:
+ ```yaml
+ if: ${{ github.repository != 'ni/labview-icon-editor' }}
+ ```
+- If the original repo name is different (e.g., `myorg/lv-icon-editor`), adjust it accordingly.
+- This ensures the workflow **knows** when it’s on a fork vs. the original repo.
+
+### **3. Ensure Runner & Permissions**
+- **Self-Hosted Runner**:
+ - The file references `runs-on: [self-hosted, iconeditor]`. Verify that your runner has both labels.
+ - If not, change `runs-on` to match your runner’s labels.
+- **Write Permissions**:
+ - In your fork’s **Settings** → **Actions** → **General**, check **Workflow Permissions** = “Read and Write.”
+ - This allows the GITHUB_TOKEN to push tags and create releases.
+
+---
+
+## **5. Workflow Behavior**
+
+### **Events That Trigger It**
+- `push` to `main`, `develop`, `release/*`, or `hotfix/*`.
+- `pull_request` targeting those branches.
+- `workflow_dispatch` (manual run) if enabled.
+
+### **Label-Based Semver Bumps**
+- On a pull request, the workflow inspects labels:
+ - `major` → X+1.0.0
+ - `minor` → X.Y+1.0
+ - `patch` → X.Y.Z+1
+- If no label, it defaults to a patch bump.
+
+### **Release Candidate Logic**
+- For branches named `release/*`, the version gets an `-rc.N` suffix (e.g., `v1.2.0-rc.3-build10`).
+- The resulting GitHub release is marked as a **pre-release**.
+- Merging from `release/*` into `main` can finalize the version.
+
+---
+
+## **6. Usage Examples**
+
+### **Pull Requests with Labels**
+- Suppose you create a PR from `feature/my-new-feature` to `develop`.
+- Assign the `minor` label to indicate a minor bump.
+- Upon merging (or push), the version might go from `v1.2.3` to `v1.3.0` plus a build number.
+
+### **Direct Push to Main or Develop**
+- If you push directly (e.g., an urgent hotfix), the workflow defaults to patch bump if no label is set.
+- It automatically tags and releases the new version: `v1.3.1-build42`, for example.
+
+### **Working on a Release Branch**
+- Branch name: `release/2.0`.
+- The workflow appends `-rc.N` to the semver (`v2.0.0-rc.2-build17`) before finalizing.
+
+---
+
+## **7. Detailed Step Explanations**
+
+### **Disable GPG Signing (if Fork)**
+- **When**: Immediately at the start of the job if `github.repository != 'ni/labview-icon-editor'`.
+- **What**:
+ - Reads existing Git config for signing.
+ - Temporarily sets `commit.gpgsign` and `tag.gpgsign` to `false`.
+- **Why**: Avoid passphrase prompts or errors if the user doesn’t have the GPG keys.
+
+### **Compute Version**
+- Checks for labels or direct push to decide the bump type.
+- Scans existing tags matching `v*.*.*-build*` to determine the next build number.
+
+### **Create Tag & Push**
+- Only runs on non-PR events (e.g., push to `develop`).
+- Uses `git tag -a vX.Y.Z-buildN` and pushes it to `origin`.
+
+### **Build the Icon Editor VI Package**
+- Invokes `Build.ps1` to compile `.vip` output inside `builds/VI Package/`.
+- **Important**: You can pass your **GitHub repository** or **organization** as parameters (e.g., `-CompanyName`, `-AuthorName`) so the final `.vip` is **branded** with your fork’s identity.
+ - For example:
+ ```yaml
+ - name: Run PowerShell Build
+ run: |
+ pwsh .\Build.ps1 `
+ -RelativePath "$env:GITHUB_WORKSPACE" `
+ -AbsolutePathScripts "$env:GITHUB_WORKSPACE\pipeline\scripts" `
+ -Major 1 -Minor 0 -Patch 0 -Build 42 `
+ -Commit "${{ github.sha }}" `
+ -CompanyName "${{ github.repository_owner }}" `
+ -AuthorName "${{ github.repository }}" `
+ -Verbose
+ ```
+- This way, the `.vip` package’s display fields clearly **indicate** who built it and from which repo.
+
+### **Upload Artifact**
+- Uses `actions/upload-artifact@v4` to store `.vip` in GitHub’s artifact section.
+- You can download this artifact from the workflow summary page.
+
+### **Create GitHub Release**
+- Also only on non-PR events.
+- Publishes a release with the newly created tag; if `-rc` suffix is present, marks it as pre-release.
+
+### **Re-Enable GPG Signing**
+- If it was disabled, the workflow reads the original signing config and restores it, ensuring local dev settings remain unchanged.
+
+---
+
+## **8. Testing & Verification**
+
+### **Fork Testing**
+1. **Fork** the repo.
+2. **Push** to your fork’s `develop` branch.
+3. Confirm the new tag appears in your fork’s tags (like `v0.0.1-build1`), and GPG signing is not prompted.
+4. Check the run logs for any errors.
+5. **Inspect** the final `.vip` file in VIPM to see that “Company Name” or “Author Name (Person or Company)” has **your** repo/fork branding.
+
+### **Main Repo Testing**
+1. **Push** or **merge** a change in `ni/labview-icon-editor`.
+2. The job will detect it’s the original repo, keep signing enabled, and produce a signed tag.
+3. Verify the `.vip` artifact is uploaded and that a release is created.
+4. Inspect the package metadata for `ni/labview-icon-editor` branding or other relevant fields.
+
+### **Pull Request Testing**
+- **Open** a PR from a feature branch to `develop`.
+- Assign `major`, `minor`, or `patch` label.
+- Observe that the workflow checks the label but does **not** create a tag or release until merged.
+- On merge, the final tag is pushed.
+
+---
+
+## **9. Troubleshooting**
+
+- **“No runner matching labels”**: Update `runs-on` or set your self-hosted runner labels.
+- **“Permission denied when pushing tag”**: Go to Settings → Actions → General and set “Workflow permissions” to “Read and write.”
+- **Build script not found**: Make sure your repo has `pipeline/scripts/Build.ps1` in the correct path or update the workflow steps accordingly.
+- **Signing errors in the original repo**: Ensure the runner has the correct GPG keys and passphrase configured, or remove signing if you don’t need it.
+- **Branded fields not showing**: Double-check your parameters in the `Build.ps1` call (e.g., `-CompanyName`, `-AuthorName`) or ensure the script itself updates JSON properly.
+
+---
+
+## **10. FAQ**
+
+**Q1**: *Can I rename the workflow file?*
+**A1**: Yes. Just keep it in `.github/workflows/`. The name inside `name:` in the YAML doesn’t affect functionality.
+
+**Q2**: *Do I need the same runner labels (`iconeditor`)?*
+**A2**: Not necessarily. You can adjust `runs-on` to any environment that has LabVIEW/PowerShell 7 installed, or uses GitHub-hosted runners with minimal changes.
+
+**Q3**: *What if I want to skip GPG signing in the main repo, too?*
+**A3**: Remove or comment out the logic checking `github.repository` and disable signing altogether.
+
+**Q4**: *What if I want to force GPG signing on forks?*
+**A4**: You must provide them with the keys or passphrase. Generally not recommended for open-source forks.
+
+**Q5**: *Why do I need to pass `-CompanyName` or `-AuthorName`?*
+**A5**: This ensures your `.vip` file is **branded** with your organization or repository. Helpful if you want to differentiate your fork’s output from the original.
+
+---
+
+## **11. Conclusion**
+
+By setting up the **Build VI Package** workflow in your repository (or fork), you gain:
+
+- **Automated versioning** with semantic increments.
+- A **straightforward** path to building and releasing `.vip` artifacts.
+- A **fork-friendly** process that avoids GPG key complexities.
+- **Optional branding** of the final package using your repository/organization metadata—making each build clearly identifiable.
+
+Simply follow the **setup steps** and **usage examples** above to enable consistent, robust releases for your Icon Editor project. **Happy building!**
diff --git a/docs/actions/development-mode-toggle.md b/docs/actions/development-mode-toggle.md
new file mode 100644
index 00000000..5e9365cc
--- /dev/null
+++ b/docs/actions/development-mode-toggle.md
@@ -0,0 +1,128 @@
+# Development Mode Toggle
+
+This document explains how to use and customize the **Development Mode Toggle** workflow, which lets you enable or disable a “development mode” on a self-hosted GitHub Actions runner. It is particularly aimed at developers contributing to NI’s (National Instruments) LabVIEW-based open-source projects.
+
+## 1. Overview
+
+### What Is “Development Mode”?
+In LabVIEW-centric projects, “development mode” usually refers to a runner state that enables additional debugging or specialized project setup. For instance, you might need to move specific set of files from Program Files, or set a Token on the LabVIEW.ini of a specific LabVIEW version before running your workflow. Turning “dev mode” on/off allows you to toggle these specialized settings quickly in order to switch your system to a state where you can install the VI Package in order to test your change and to distribute it for others to test as well.
+
+### Purpose of This Workflow
+- Makes it easy for collaborators to set a **self-hosted runner** (their own machine or a shared one) to a special “development” state without having to do it manually, taking into consideration that this will have to happen multiple times in the development phase.
+- Can be triggered manually (via `workflow_dispatch`) or from other workflows (via `workflow_call`).
+- Lets you quickly switch back to a **testable** state when you’re done coding so you can install the final VI Package to test your change.
+- Allows collaborators to **experiment with or update the order of operations** in the underlying PowerShell scripts on their own fork, then propose those changes via pull requests if they happen to improve our overall process.
+
+**Note**: Contributors who fork this repository can keep their local copy of `.github/workflows/toggle-dev-mode.yml` and its associated PowerShell scripts up to date by frequently pulling changes from the upstream repository. Likewise, if they make improvements to the scripts in their fork, they can open a pull request to merge those improvements back upstream.
+
+## 2. Usage
+
+You do **not** need to copy/paste the entire workflow snippet here, as it’s already in your repo (“Development mode toggle”). Instead, here is a conceptual usage overview:
+
+1. **Triggering Manually**
+ - Go to the “Actions” tab on your (or your fork’s) GitHub repository.
+ - Select the **“Toggle Development Mode”** workflow.
+ - Click “Run workflow” and choose either `enable` or `disable` from the dropdown.
+ - This will execute the PowerShell scripts (`Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1`) on the **target self-hosted runner** (your personal machine or a shared machine).
+
+2. **Important Note for Testing**
+ - If your system is set to dev mode (`enable`), you wont be able to open the icon editor after you install the VI Package.
+ - **Once you finish coding** or making changes, **switch back** (`disable`) to a normal testable state to be able to install the VI Package and test your change.
+
+3. **Triggering from Another Workflow**
+ - Use a `workflow_call` reference (detailed examples below).
+ - Pass the input parameter `mode` set to `enable` or `disable`.
+ - The runner that calls it will be the one switched into (or out of) dev mode.
+
+## 3. Examples: Calling This Workflow
+
+Below are **three** ways to invoke this workflow. Each approach sets `mode` to either `enable` or `disable`.
+
+### 3.1 Call from Another Workflow in the Same Repository
+
+If you have another workflow file (e.g., `my-other-workflow.yml`) in the same repo, you can reference “Development mode toggle” by its local path:
+
+ # my-other-workflow.yml
+ name: "My Other Workflow"
+
+ on:
+ workflow_dispatch:
+
+ jobs:
+ call-dev-mode:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Invoke Dev Mode Toggle (enable)
+ uses: ./.github/workflows/toggle-dev-mode.yml
+ with:
+ mode: enable
+
+1. `uses: ./.github/workflows/toggle-dev-mode.yml` – Tells GitHub to run a local reusable workflow found in your repo.
+2. `with:` – Passes inputs to that workflow. Here, `mode: enable`.
+
+### 3.2 Call from Another Repository (Direct GitHub Reference)
+
+If you store “Development mode toggle” in a separate public repo, you can reference it by the GitHub org/repo and the specific path/branch:
+
+ name: "Cross-Repo Dev Mode Toggle"
+
+ on:
+ workflow_dispatch:
+
+ jobs:
+ remote-dev-mode:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Use remote Dev Mode Toggle
+ uses: //.github/workflows/toggle-dev-mode.yml@main
+ with:
+ mode: disable
+
+1. Replace `/` with the actual GitHub account and repository name (for example, `ni/my-shared-workflows`).
+2. The suffix `@main` indicates which branch/ref to fetch. You can also use a tag or commit SHA.
+3. Inputs like `mode` are passed the same way.
+
+### 3.3 Call from a Fork
+
+If a collaborator forked your original repo, they might keep the workflow in their own fork. They can reference that fork directly:
+
+ name: "Forked Dev Mode Example"
+
+ on:
+ workflow_dispatch:
+
+ jobs:
+ forked-workflow-call:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Call Dev Mode Toggle from My Fork
+ uses: //.github/workflows/toggle-dev-mode.yml@my-feature-branch
+ with:
+ mode: enable
+
+Here, you might see something like `githubuser/labview-icon-editor-fork/.github/workflows/toggle-dev-mode.yml@feature-xyz`. Again, you pass the `mode` input as needed. Whenever upstream changes are made to the scripts, the fork owner can **pull** to update their local `.github/workflows/toggle-dev-mode.yml` file.
+
+---
+
+## 4. Customization
+
+All “dev mode” logic resides in two PowerShell scripts:
+
+- **`Set_Development_Mode.ps1`** – Called when mode is `enable`.
+- **`RevertDevelopmentMode.ps1`** – Called when mode is `disable`.
+
+These scripts currently do things like update environment variables, configure LabVIEW paths, or install certain dependencies. **To change** how “dev mode” behaves, **edit those scripts** directly.
+
+### Pull Requests with Script Updates
+Collaborators are free to:
+1. **Modify** `Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1` on their forks.
+2. **Enable dev mode** on their self-hosted runner (via their fork), capturing the GitHub Actions logs as proof that their changes worked as intended.
+3. **Open a Pull Request** to merge these script changes back into the upstream repository, referencing the successful action logs as additional evidence.
+
+---
+
+## 5. Additional Resources
+- Refer to your README.md for details on setting up your runner (LabVIEW requirements, etc.).
+- GitHub Docs: https://docs.github.com/en/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow
+
+---
diff --git a/docs/actions/icon-editor-github-runner-setup-guide.md b/docs/actions/icon-editor-github-runner-setup-guide.md
new file mode 100644
index 00000000..3d836e54
--- /dev/null
+++ b/docs/actions/icon-editor-github-runner-setup-guide.md
@@ -0,0 +1,254 @@
+# **icon-editor-github-runner-setup-guide.md**
+
+This document describes a **complete guide** to setting up and using the “Build VI Package” GitHub Actions workflow in your repository—whether it's the original (`ni/labview-icon-editor`) or a **fork**. It explains each part of the workflow, including **how to configure it**, **why certain design choices were made**, and **what steps** you must follow to replicate this functionality on your own fork.
+
+---
+
+## **Table of Contents**
+
+1. [Overview](#overview)
+2. [Why Use This Workflow?](#why-use-this-workflow)
+3. [Core Features](#core-features)
+ - [1. Automatic Versioning](#1-automatic-versioning)
+ - [2. GPG Signing Toggle](#2-gpg-signing-toggle)
+ - [3. Artifact Build & Release](#3-artifact-build--release)
+ - [4. Custom Branding (Repo/Org)](#4-custom-branding-repoorg)
+4. [Setting Up in Your Fork](#setting-up-in-your-fork)
+ - [1. Copy the Workflow File](#1-copy-the-workflow-file)
+ - [2. Update the Repository Check](#2-update-the-repository-check)
+ - [3. Ensure Runner & Permissions](#3-ensure-runner--permissions)
+5. [Workflow Behavior](#workflow-behavior)
+ - [Events That Trigger It](#events-that-trigger-it)
+ - [Label-Based Semver Bumps](#label-based-semver-bumps)
+ - [Release Candidate Logic](#release-candidate-logic)
+6. [Usage Examples](#usage-examples)
+ - [Pull Requests with Labels](#pull-requests-with-labels)
+ - [Direct Push to Main or Develop](#direct-push-to-main-or-develop)
+ - [Working on a Release Branch](#working-on-a-release-branch)
+7. [Detailed Step Explanations](#detailed-step-explanations)
+ - [Disable GPG Signing (if Fork)](#disable-gpg-signing-if-fork)
+ - [Compute Version](#compute-version)
+ - [Create Tag & Push](#create-tag--push)
+ - [Build the Icon Editor VI Package](#build-the-icon-editor-vi-package)
+ - [Upload Artifact](#upload-artifact)
+ - [Create GitHub Release](#create-github-release)
+ - [Re-Enable GPG Signing](#re-enable-gpg-signing)
+8. [Testing & Verification](#testing--verification)
+ - [Fork Testing](#fork-testing)
+ - [Main Repo Testing](#main-repo-testing)
+ - [Pull Request Testing](#pull-request-testing)
+9. [Troubleshooting](#troubleshooting)
+10. [FAQ](#faq)
+11. [Conclusion](#conclusion)
+
+---
+
+## **1. Overview**
+
+**Purpose**: This workflow provides a **consistent, automated release process** for LabVIEW Icon Editor packages, including:
+
+- Automatic **Semantic Version** bumping (major/minor/patch).
+- **Build** and **packaging** of the `.vip` artifact.
+- **Tag creation** in Git with a `vX.Y.Z-buildN` format.
+- **GitHub Release** creation, optionally as a pre-release if using a `release/*` branch.
+
+For **forks**, the workflow automatically **disables** GPG signing to avoid passphrase prompts.
+
+---
+
+## **2. Why Use This Workflow?**
+
+1. **Standardizes versioning**: Eliminates confusion about version increments; labels guide the semver bump.
+2. **Fork-friendly**: Fork owners won’t be blocked by GPG passphrase issues.
+3. **Reduces manual overhead**: No more ad-hoc tagging, manual artifact uploads, or drafting releases.
+4. **Encourages best practices**: Integrates cleanly with GitHub’s PR and branching model.
+5. **Unique build branding**: You can **inject custom organization/repo metadata** into the `.vip` package, making it clear which fork or repo produced the Icon Editor.
+
+---
+
+## **3. Core Features**
+
+### **1. Automatic Versioning**
+- Pull request labels (`major`, `minor`, `patch`) decide how much to increment the version.
+- Defaults to a `patch` bump if there’s no label or on direct pushes.
+
+### **2. GPG Signing Toggle**
+- If the repository name **is** `ni/labview-icon-editor`, signing stays enabled.
+- If **not**, the workflow disables signing, preventing passphrase prompts that occur when no keys are available on the fork’s runner.
+- Restores any prior Git config after the build completes.
+
+### **3. Artifact Build & Release**
+- Runs a PowerShell script (`Build.ps1`) to compile `.vip` output.
+- Uploads the `.vip` to GitHub as a build artifact.
+- **Creates a release** in GitHub if it’s not a pull request, attaching the `.vip`.
+
+### **4. Custom Branding (Repo/Org)**
+- **Why**: Multiple teams or forks may produce their own **Icon Editor** packages. Embedding a **company name**, **GitHub organization**, or **repository name** helps uniquely identify who built each `.vip`.
+- **How**:
+ - The workflow passes extra parameters (like `-CompanyName`, `-AuthorName`) to **Build.ps1**.
+ - This metadata is injected into the **DisplayInformationJSON** for the VI Package.
+ - In GitHub Actions, you can leverage `${{ github.repository_owner }}` or `${{ github.repository }}` to auto-fill those fields from your fork’s context.
+ - Users installing the package can then see **which** organization or repository it came from (e.g., “AcmeCorp/lv-icon-editor”).
+
+---
+
+## **4. Setting Up in Your Fork**
+
+### **1. Copy the Workflow File**
+- In your fork, create a new file:
+ `.github/workflows/build-vi-package.yml`
+- Copy the entire workflow YAML from the main repo or from a PR that merges these changes.
+- Commit it to your fork’s branch (e.g., `develop`).
+
+### **2. Update the Repository Check**
+- Locate lines like:
+ ```yaml
+ if: ${{ github.repository != 'ni/labview-icon-editor' }}
+ ```
+- If the original repo name is different (e.g., `myorg/lv-icon-editor`), adjust it accordingly.
+- This ensures the workflow **knows** when it’s on a fork vs. the original repo and can disable or enable GPG signing correctly.
+
+### **3. Ensure Runner & Permissions**
+- **Self-Hosted Runner**:
+ - The file references `runs-on: [self-hosted, iconeditor]`. Verify that your runner has both labels.
+ - If not, change `runs-on` to match your runner’s labels.
+- **Write Permissions**:
+ - In your fork’s **Settings** → **Actions** → **General**, check **Workflow Permissions** = “Read and Write.”
+ - This allows the GITHUB_TOKEN to push tags and create releases.
+
+---
+
+## **5. Workflow Behavior**
+
+### **Events That Trigger It**
+- `push` to `main`, `develop`, `release/*`, or `hotfix/*`.
+- `pull_request` targeting those branches.
+- `workflow_dispatch` (manual run) if enabled.
+
+### **Label-Based Semver Bumps**
+- On a pull request, the workflow inspects labels:
+ - `major` → X+1.0.0
+ - `minor` → X.Y+1.0
+ - `patch` → X.Y.Z+1
+- If no label, it defaults to a patch bump.
+
+### **Release Candidate Logic**
+- For branches named `release/*`, the version gets an `-rc.N` suffix (e.g., `v1.2.0-rc.3-build10`).
+- The resulting GitHub release is marked as a **pre-release**.
+- Merging from `release/*` into `main` can finalize the version.
+
+---
+
+## **6. Usage Examples**
+
+### **Pull Requests with Labels**
+- Suppose you create a PR from `feature/my-new-feature` to `develop`.
+- Assign the `minor` label to indicate a minor bump.
+- Upon merging (or push), the version might go from `v1.2.3` to `v1.3.0` plus a build number.
+
+### **Direct Push to Main or Develop**
+- If you push directly (e.g., an urgent hotfix), the workflow defaults to patch bump if no label is set.
+- It automatically tags and releases the new version: `v1.3.1-build42`.
+
+### **Working on a Release Branch**
+- Branch name: `release/2.0`.
+- The workflow appends `-rc.N` to the semver (`v2.0.0-rc.2-build17`) before finalizing.
+
+---
+
+## **7. Detailed Step Explanations**
+
+### **Disable GPG Signing (if Fork)**
+- **When**: Immediately at the start of the job if `github.repository != 'ni/labview-icon-editor'`.
+- **What**:
+ - Reads existing Git config for signing.
+ - Temporarily sets `commit.gpgsign` and `tag.gpgsign` to `false`.
+- **Why**: Avoid passphrase prompts or errors if the user doesn’t have the GPG keys.
+
+### **Compute Version**
+- Checks for labels or direct push to decide the bump type.
+- Scans existing tags matching `v*.*.*-build*` to determine the next build number.
+
+### **Create Tag & Push**
+- Only runs on non-PR events (e.g., push to `develop`).
+- Uses `git tag -a vX.Y.Z-buildN` and pushes it to `origin`.
+
+### **Build the Icon Editor VI Package**
+- Invokes `Build.ps1` to compile `.vip` output inside `builds/VI Package/`.
+- **Injects Branding**: The PowerShell script merges parameters like `-CompanyName` and `-AuthorName` into the JSON that customizes the VI Package’s **Display Information**.
+ - This ensures your build includes references to **which** organization or **repo** produced it.
+
+### **Upload Artifact**
+- Uses `actions/upload-artifact@v4` to store `.vip` in GitHub’s artifact section.
+- You can download this artifact from the workflow summary page.
+
+### **Create GitHub Release**
+- Also only on non-PR events.
+- Publishes a release with the newly created tag; if `-rc` suffix is present, marks it as pre-release.
+
+### **Re-Enable GPG Signing**
+- If it was disabled, the workflow restores any original signing config.
+
+---
+
+## **8. Testing & Verification**
+
+### **Fork Testing**
+1. **Fork** the repo.
+2. **Push** to your fork’s `develop` branch.
+3. Confirm the new tag appears in your fork’s tags (like `v0.0.1-build1`), and that GPG signing is not prompted.
+4. Check the run logs for any errors.
+5. **Verify** the final `.vip` includes your fork’s branding (for example, `CompanyName: "Acme Corp"`).
+
+### **Main Repo Testing**
+1. **Push** or **merge** a change in `ni/labview-icon-editor`.
+2. The job will detect it’s the original repo, keep signing enabled, and produce a signed tag.
+3. Verify the `.vip` artifact is uploaded and that a release is created.
+
+### **Pull Request Testing**
+- **Open** a PR from a feature branch to `develop`.
+- Assign `major`, `minor`, or `patch` label.
+- Observe that the workflow checks the label but does **not** create a tag or release until merged.
+- On merge, the final tag is pushed and the `.vip` is built.
+
+---
+
+## **9. Troubleshooting**
+
+- **“No runner matching labels”**: Update `runs-on` or set your self-hosted runner labels.
+- **“Permission denied when pushing tag”**: Go to Settings → Actions → General and set “Workflow permissions” to “Read and write.”
+- **Build script not found**: Make sure your repo has `pipeline/scripts/Build.ps1` in the correct path or update the workflow steps accordingly.
+- **Signing errors in the original repo**: Ensure the runner has the correct GPG keys and passphrase configured, or remove signing if you don’t need it.
+- **Branding not updated**: Double-check you’re passing `-CompanyName` and `-AuthorName` to `Build.ps1`. If you’re referencing GitHub environment variables, ensure you spelled them correctly.
+
+---
+
+## **10. FAQ**
+
+**Q1**: *Can I rename the workflow file?*
+**A1**: Yes. Just keep it in `.github/workflows/`. The name inside `name:` in the YAML doesn’t affect functionality.
+
+**Q2**: *Do I need the same runner labels (`iconeditor`)?*
+**A2**: Not necessarily. You can adjust `runs-on` to any environment that has LabVIEW/PowerShell 7 installed, or uses GitHub-hosted runners with minimal changes.
+
+**Q3**: *What if I want to skip GPG signing in the main repo, too?*
+**A3**: Remove or comment out the logic checking `github.repository` and disable signing altogether.
+
+**Q4**: *How do I pass my GitHub org and repo info to the VI Package?*
+**A4**: In your workflow YAML, supply `-CompanyName "${{ github.repository_owner }}"` and `-AuthorName "${{ github.repository }}"` (or a variation). The build script merges those fields into the `.vip` metadata.
+
+**Q5**: *What if I want to force GPG signing on forks?*
+**A5**: You must provide them with the keys or passphrase. Generally not recommended for open-source forks.
+
+---
+
+## **11. Conclusion**
+
+By setting up the **Build VI Package** workflow in your repository (or fork), you gain:
+
+- **Automated versioning** with semantic increments.
+- A **straightforward** path to building and releasing `.vip` artifacts with **custom branding** for your organization or repo.
+- A **fork-friendly** process that avoids GPG key complexities.
+
+Simply follow the **setup steps** and **usage examples** above to enable consistent, robust releases for your Icon Editor project.
+Happy building!
\ No newline at end of file
diff --git a/docs/actions/injecting-repo-org-to-vi-package.md b/docs/actions/injecting-repo-org-to-vi-package.md
new file mode 100644
index 00000000..52977561
--- /dev/null
+++ b/docs/actions/injecting-repo-org-to-vi-package.md
@@ -0,0 +1,128 @@
+# Injecting Repo Name and Organization into the LabVIEW VI Package
+
+This document explains how we leverage **PowerShell** scripts and **GitHub Actions** to insert **repository** and **organization** metadata into the LabVIEW Icon Editor’s VI Package, ensuring each build is **unique** and **traceable**.
+
+---
+
+## Table of Contents
+1. [Overview](#overview)
+2. [Why Inject Repo/Org Fields?](#why-inject-repoorg-fields)
+3. [GitHub Actions and PowerShell](#github-actions-and-powershell)
+4. [Overall CI/CD Flow](#overall-cicd-flow)
+5. [Example Usage](#example-usage)
+6. [Conclusion](#conclusion)
+
+---
+
+## Overview
+
+In a multi-fork or multi-organization environment, **injecting the repository name and organization** into the VI Package:
+- Creates distinct **branding** or “ownership” for each fork.
+- Lets end users quickly see **which** organization built the Icon Editor.
+- Maintains **consistent** versioning and naming conventions across builds.
+
+We achieve this by:
+1. **Constructing** a JSON object in `Build.ps1` that sets fields like:
+ - `"Company Name"`
+ - `"Author Name (Person or Company)"`
+2. **Calling** `build_vip.ps1`, which **parses** the JSON and **updates** the `.vipb` (VI Package Builder) file.
+3. **Using** GitHub Actions environment variables (like `${{ github.repository_owner }}`) to pass the org name, and `${{ github.repository }}` for the repository name.
+
+---
+
+## Why Inject Repo/Org Fields?
+
+1. **Unique Identification**
+ - If multiple teams produce their own version of the Icon Editor, each package can show **where** it came from.
+ - Avoids confusion when you have multiple `.vip` files with similar names.
+
+2. **Traceability**
+ - When debugging or updating an installed package, you can see **which** organization or Git repo built it, ensuring faster troubleshooting.
+
+3. **Automated Metadata**
+ - No manual editing: The build scripts automatically **pull** the organization and repo name from GitHub Actions, so the package metadata is always up-to-date.
+
+---
+
+## GitHub Actions and PowerShell
+
+A typical **GitHub Actions** workflow might have steps like:
+
+```yaml
+name: Build LabVIEW Icon Editor
+on:
+ push:
+ branches: [ "main" ]
+
+jobs:
+ build:
+ runs-on: windows-latest
+ steps:
+ - name: Check out repository
+ uses: actions/checkout@v3
+
+ - name: Setup PowerShell
+ uses: actions/setup-powershell@v2
+
+ - name: Run PowerShell Build
+ run: |
+ pwsh .\Build.ps1 `
+ -RelativePath "$env:GITHUB_WORKSPACE" `
+ -AbsolutePathScripts "$env:GITHUB_WORKSPACE\pipeline\scripts" `
+ -Major 1 -Minor 0 -Patch 0 -Build 42 `
+ -Commit "${{ github.sha }}" `
+ -CompanyName "${{ github.repository_owner }}" `
+ -AuthorName "${{ github.repository }}" `
+ -Verbose
+```
+
+**Key points**:
+- **`${{ github.repository_owner }}`** is the **organization** (or user) that owns the repo.
+- **`${{ github.repository }}`** is the “orgName/repoName” string (e.g. `AcmeCorp/lv-icon-editor`).
+- These parameters feed into the final **JSON** that `build_vip.ps1` uses to update the VI Package.
+
+---
+
+## Overall CI/CD Flow
+
+1. **Developer** pushes code to GitHub.
+2. **GitHub Actions** triggers the workflow.
+3. **Actions** checks out the repo and runs `Build.ps1`:
+ 1. Cleans old artifacts.
+ 2. Applies VIPC (32-bit and 64-bit).
+ 3. Builds the 32-bit and 64-bit libraries.
+ 4. Constructs JSON containing `CompanyName` and `AuthorName` fields, derived from GitHub Action variables.
+ 5. Passes that JSON to `build_vip.ps1`.
+ 6. `build_vip.ps1` injects these fields and version info into the `.vipb` file.
+ 7. Generates the **Icon Editor** `.vip` package.
+4. **Actions** can then publish or attach the final `.vip` as an artifact.
+
+---
+
+## Example Usage
+
+### Local Command-Line
+
+You can also run this locally. For example, if you wanted to embed some custom organization and repo data manually:
+
+```powershell
+.\Build.ps1 `
+ -RelativePath "C:\labview-icon-editor-fork" `
+ -AbsolutePathScripts "C:\labview-icon-editor-fork\pipeline\scripts" `
+ -Major 2 -Minor 1 -Patch 0 -Build 5 `
+ -Commit "abc12345" `
+ -CompanyName "Acme Corporation" `
+ -AuthorName "acme-corp/lv-icon-editor" `
+ -Verbose
+```
+
+This produces a `.vip` file that, when inspected in VIPM or LabVIEW, shows **“Acme Corporation”** as the company and **“acme-corp/lv-icon-editor”** in the author field.
+
+---
+
+## Conclusion
+
+**Injecting Repo and Organization** fields in the Icon Editor’s VI Package ensures:
+- Each fork or organization can **uniquely** brand its builds.
+- CI/CD with **GitHub Actions** automatically **populates** build metadata, removing manual steps.
+- You have a **clear**, **traceable** record of each build’s origin—particularly useful in multi-team or open-source projects.
diff --git a/docs/automated-setup.md b/docs/automated-setup.md
new file mode 100644
index 00000000..c0b4adb6
--- /dev/null
+++ b/docs/automated-setup.md
@@ -0,0 +1,194 @@
+
+# Automated Setup & Editing Instructions
+
+This document describes how to **build, test, and distribute** the **LabVIEW Icon Editor** using **PowerShell**. You can run these scripts locally on your development or self-hosted runner, or within **GitHub Actions**. By making this process open source, we enable community collaboration, easier troubleshooting, and a more transparent build pipeline for the Icon Editor that ships with LabVIEW.
+
+## Table of Contents
+
+1. [Overview & Prerequisites](#overview--prerequisites)
+2. [Editing Guide (PowerShell)](#editing-guide-powershell)
+3. [Distribution Guide (VI Package via PowerShell)](#distribution-guide-vi-package-via-powershell)
+4. [Integrating with GitHub Actions](#integrating-with-github-actions)
+5. [How `Build.ps1` Works](#how-buildps1-works)
+6. [Local vs. CI Usage](#local-vs-ci-usage)
+7. [Example Developer Workflow](#example-developer-workflow)
+
+---
+
+
+## 1. Overview & Prerequisites
+
+- **Purpose**: Provide a **PowerShell-centric** approach to build, test, and package the Icon Editor—either locally or via GitHub Actions.
+- **Why PowerShell?**:
+ - Simplifies applying VIPCs, building `.lvlibp`, and producing a `.vip` artifact.
+ - Debug locally the same steps used in CI, ensuring consistent results.
+
+- **Prerequisites**:
+ 1. **LabVIEW 2021 SP1 (both 32-bit & 64-bit)**.
+ 2. **PowerShell 7+** and **Git**.
+ 3. **Apply** `tooling\deployment\runner_dependencies.vipc` **(to both 32-bit & 64-bit)**.
+
+---
+
+
+## 2. Editing Guide (PowerShell)
+
+1. **Back Up** (highly recommended):
+ `\resource\plugins\lv_icon.lvlibp`
+ `\vi.lib\LabVIEW Icon API`
+
+2. **Clone** the [Icon Editor](https://github.com/ni/labview-icon-editor.git) to your development location.
+
+3. **Apply** dependencies:
+ `Tooling\deployment\runner_dependencies.vipc` to **LabVIEW 2021 (32-bit) & LabVIEW 2021 (64-bit)**.
+
+4. **Open** PowerShell (Admin):
+ Navigate to your working directory `pipeline\scripts`
+
+5. **Enable Dev Mode**:
+ ```powershell
+ .\Set_Development_Mode.ps1 -RelativePath "C:\labview-icon-editor"
+ ```
+
+ Removes the default `lv_icon.lvlibp` and points LabVIEW to your local Icon Editor code.
+
+6. **Open** the project:
+ `lv_icon_editor.lvproj`
+ Edit the Icon Editor source as needed.
+
+---
+
+
+## 3. Distribution Guide (VI Package via PowerShell)
+
+1. **Apply Dependencies** in VIPM:
+ - Set LabVIEW to 2021 (32-bit), apply `Tooling\deployment\runner_dependencies.vipc`.
+ - Repeat for 64-bit if necessary.
+
+2. **Disable LabVIEW Security Warnings** *(to prevent popups from "run when opened" VIs)*:
+ - **Tools → Options → Security** → **Run VI Without Warnings**.
+
+3. **Open** PowerShell (Admin), go to:
+ ```powershell
+ cd pipeline\scripts
+ ```
+
+4. **Run** `Build.ps1`:
+ ```powershell
+ .\Build.ps1 `
+ -RelativePath "C:\labview-icon-editor" `
+ -AbsolutePathScripts "C:\labview-icon-editor\pipeline\scripts" `
+ -Major 1 -Minor 2 -Patch 3 -Build 45 `
+ -Commit "my-commit-sha" `
+ -LabVIEWMinorRevision 3 `
+ -Verbose
+ ```
+ This generates a `.vip` in `builds\VI Package`.
+
+5. **Revert Dev Mode (optional)**:
+ ```powershell
+ .\RevertDevelopmentMode.ps1 -RelativePath "C:\labview-icon-editor"
+ ```
+
+6. **Install** the `.vip` in VIPM (as Admin). Validate your custom Icon Editor changes.
+
+---
+
+
+## 4. Integrating with GitHub Actions
+
+We provide **GitHub Actions** that wrap these same PowerShell scripts for building the Icon Editor:
+
+- **Development Mode Toggle**: Uses `Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1`.
+- **Run Unit Tests**: Calls `unit_tests.ps1`.
+- **Build VI Package & Release**: Internally calls `Build.ps1` to produce a `.vip` and create a GitHub Release.
+
+### Injecting Organization/Repo for Unique Builds
+
+In many workflows, you may want the **organization** or **repository** name **injected** into the VI Package to brand the build uniquely. For instance, if you have a GitHub Actions workflow, you can pass environment variables like `${{ github.repository_owner }}` (the org or user) and `${{ github.repository }}` (e.g. `myorg/myfork`) to `Build.ps1`. This is useful when:
+
+- **Maintaining multiple forks** that each produce their own Icon Editor package.
+- **Distinguishing** who built the editor if multiple variants circulate internally.
+
+An example step in a GitHub Actions file might look like:
+
+```yaml
+- name: Build Icon Editor
+ run: |
+ pwsh .\Build.ps1 `
+ -RelativePath "$env:GITHUB_WORKSPACE" `
+ -AbsolutePathScripts "$env:GITHUB_WORKSPACE\pipeline\scripts" `
+ -Major 1 -Minor 2 -Patch 0 -Build 10 `
+ -Commit "${{ github.sha }}" `
+ # You can pass metadata fields to brand the package:
+ -CompanyName "${{ github.repository_owner }}" `
+ -AuthorName "${{ github.repository }}" `
+ -Verbose
+```
+
+Passing these metadata fields ensures the final `.vip` clearly identifies **which fork** built it, and under **which organization**.
+
+**Key Points**:
+- The scripts you run locally are **exactly** what the GitHub Actions will call.
+- Makes debugging/troubleshooting simpler since you can mirror CI steps locally.
+- The build process is **open source**, letting contributors collaborate on the same scripts that ship the official LabVIEW Icon Editor.
+
+---
+
+
+## 5. How `Build.ps1` Works
+
+`Build.ps1` orchestrates the entire build pipeline for the Icon Editor:
+
+1. **Cleans up** old `.lvlibp` files in `resource\plugins`.
+2. **Applies** VIPC for both 32-bit & 64-bit LabVIEW.
+3. **Builds** each bitness of the library (passing version info: `-Major`, `-Minor`, `-Patch`, `-Build`, `-Commit`).
+4. **Renames** results (`lv_icon_x86.lvlibp`, `lv_icon_x64.lvlibp`).
+5. **Constructs** JSON data (including optional fields for organization, repo name, etc.).
+6. **Builds** the final `.vip` (64-bit) with `build_vip.ps1`:
+ - The **metadata** you pass (like `CompanyName` and `AuthorName`) gets placed into the **Display Information** section of the `.vipb` file to **brand** the package.
+ - The optional `-LabVIEWMinorRevision` parameter can override default minor version logic.
+
+7. **Closes** LabVIEW sessions in between steps.
+
+### Why Inject Repo/Org Fields?
+
+- **Unique Identification**: If multiple teams or forks produce an Icon Editor build, the `.vip` can identify **who** built it.
+- **Traceability**: Makes it easy to see the GitHub org/repo of the build in VIPM or LabVIEW’s “About” screen.
+- **No Manual Edits**: The script automatically merges your provided fields, so you don’t have to manually edit JSON or `.vipb` each time.
+
+---
+
+
+## 6. Local vs. CI Usage
+
+1. **Local**:
+ - Enable dev mode → Edit code → Run `Build.ps1` → (Optionally) revert dev mode.
+ - You can pass additional metadata arguments to brand your `.vip` locally, too.
+
+2. **CI (GitHub Actions)**:
+ - Same scripts run automatically or on demand.
+ - Pull requests can increment version (major/minor/patch) and produce `.vip`.
+ - Optionally inject the organization and repository name to **brand** each build.
+
+---
+
+
+## 7. Example Developer Workflow
+
+1. **Enable Dev Mode**
+ - `Set_Development_Mode.ps1` or a “Development Mode Toggle” workflow run.
+2. **Develop & Test**
+ - Locally or via “Run Unit Tests” to confirm changes.
+3. **Open PR**
+ - Label (`major`, `minor`, `patch`) for semver bump.
+ - Actions use `Build.ps1` to produce `.vip` on merges.
+4. **Merge**
+ - Creates a GitHub Release, attaches the `.vip`.
+5. **Disable Dev Mode**
+ - Revert environment.
+6. **Install**
+ - Use VIPM to install the `.vip` and confirm final functionality.
+
+All scripts are fully open source—**collaborators** can debug or extend them locally with minimal friction. By passing organization/repo data in either local builds or GitHub Actions, you ensure your **unique** version of the Icon Editor is **clearly labeled** and **easily traced** to its source.
+
diff --git a/docs/ci-workflows.md b/docs/ci-workflows.md
new file mode 100644
index 00000000..9b4faa51
--- /dev/null
+++ b/docs/ci-workflows.md
@@ -0,0 +1,171 @@
+# Local CI/CD Workflows
+
+This document explains how to automate build, test, and distribution steps for the Icon Editor using GitHub Actions. It includes features such as **fork-friendly GPG signing** toggles, **automatic version bumping** (using labels), and the **release creation** process. Additionally, it shows how you can **brand** the resulting VI Package with **organization** and **repository** metadata for unique identification.
+
+---
+
+## Table of Contents
+
+1. [Introduction](#1-introduction)
+2. [Quickstart](#2-quickstart)
+3. [Detailed Guide](#3-detailed-guide)
+ 1. [Development vs. Testing](#31-development-vs-testing)
+ 2. [Available CI Workflows](#32-available-ci-workflows)
+ 3. [Setting Up a Self-Hosted Runner](#33-setting-up-a-self-hosted-runner)
+ 4. [Running the Actions Locally](#34-running-the-actions-locally)
+ 5. [Example Developer Workflow](#35-example-developer-workflow)
+
+---
+
+## 1. Introduction
+
+Automating your Icon Editor builds and tests:
+- Provides consistent steps for every commit or pull request
+- Minimizes manual toggling of LabVIEW environment settings
+- Stores build artifacts (VI Packages) in GitHub for easy download
+- Automatically versions releases using **semantic version** logic
+- Handles GPG signing in the main repo but **disables** it for forks (so fork owners aren’t blocked by passphrase prompts)
+- **Allows you to brand** each VI Package build with your organization or repository name for unique identification
+
+**Prerequisites**:
+- LabVIEW 2021 SP1 (32 and 64-bit)
+- PowerShell 7+
+- Git for Windows
+
+---
+
+## 2. Quickstart
+
+1. **Install PowerShell & Git**
+ Ensure your environment has the required tools before setting up the workflows.
+
+2. **Configure a Self-Hosted Runner**
+ Under **Settings → Actions → Runners** in your GitHub repo or organization, add a runner with LabVIEW installed.
+
+3. **Enable/Disable Development Mode**
+ You can toggle Development Mode either via the “Development Mode Toggle” workflow or manually.
+ - Development Mode modifies `labview.ini` to reference your local source code.
+
+4. **Run Unit Tests**
+ Use the **Run Unit Tests** workflow to confirm your environment is valid.
+ - Typically run with Dev Mode **disabled** unless you’re testing dev features specifically.
+
+5. **Build VI Package & Release**
+ - Produces `.vip` artifacts automatically, **including** optional metadata fields (`-CompanyName`, `-AuthorName`) that let you **brand** your package.
+ - Uses **label-based** version bumping (major/minor/patch) on pull requests.
+ - Creates tags and releases for direct pushes (unless it’s a PR).
+
+6. **Disable Dev Mode** (optional)
+ Reverts your environment to normal LabVIEW settings, removing local overrides.
+
+**Note**: Passing metadata fields like `-CompanyName` or `-AuthorName` to the build script helps incorporate your **organization** or **repo** name directly into the final VI Package. This makes your build easily distinguishable from other forks or variants.
+
+---
+
+## 3. Detailed Guide
+
+### 3.1 Development vs. Testing
+
+- **Development Mode**:
+ A specialized configuration where LabVIEW references local paths for the Icon Editor code. Useful for debugging or certain dev features.
+ - Enable via `Set_Development_Mode.ps1` or the **Development Mode Toggle** workflow.
+
+- **Testing / Distributable Builds**:
+ Typically done in **normal** LabVIEW mode. If you forget to disable Dev Mode, tests or builds might rely on your local dev environment in unexpected ways.
+
+---
+
+### 3.2 Available CI Workflows
+
+Below are the **key GitHub Actions** provided in this repository:
+
+1. **[Development Mode Toggle](https://github.com/ni/labview-icon-editor/actions/workflows/development-mode-toggle.yml)**
+ - Invokes `Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1`.
+ - Usually triggered via `workflow_dispatch` for manual toggling.
+
+2. **[Build VI Package & Release](https://github.com/ni/labview-icon-editor/actions/workflows/build-vi-package.yml)**
+ - **Automatically** versions your code based on PR labels (`major`, `minor`, `patch`) or defaults to `patch` for direct pushes.
+ - Uses a **build counter** to ensure each artifact is uniquely numbered (e.g., `v1.2.3-build4`).
+ - **Fork-Friendly**: Disables GPG signing if it detects a fork (so no passphrase is needed). In the **main repo** (`ni/labview-icon-editor`), signing remains active.
+ - Produces the `.vip` file via a PowerShell script (e.g., `Build.ps1`).
+ - **You can pass metadata** (e.g., `-CompanyName`, `-AuthorName`) to embed your organization or repository into the generated `.vip` for distinct branding.
+ - Uploads the `.vip` artifact to GitHub’s build artifacts.
+ - Creates a **GitHub Release** for direct pushes (not for PRs).
+
+3. **[Run Unit Tests](https://github.com/ni/labview-icon-editor/actions/workflows/run-unit-tests.yml)**
+ - Executes `unit_tests.ps1` in `pipeline/scripts`.
+ - Usually expects Dev Mode **disabled** for consistent test results.
+ - Also triggered on pull requests for validation.
+
+---
+
+### 3.3 Setting Up a Self-Hosted Runner
+
+1. **Install Prerequisites**:
+ - LabVIEW 2021 SP1
+ - PowerShell 7+
+ - Git for Windows
+
+2. **Add Self-Hosted Runner**:
+ Go to **Settings → Actions → Runners** in your GitHub repository (or organization) and follow the steps to register a runner on your machine that has LabVIEW installed.
+
+3. **Label the Runner** (optional):
+ - You may label it `self-hosted, iconeditor` (or adjust the workflow’s `runs-on` lines to match your chosen labels).
+ - This helps ensure the correct environment is used for building the Icon Editor.
+
+---
+
+### 3.4 Running the Actions Locally
+
+Although GitHub Actions primarily runs on GitHub-hosted or self-hosted agents, you can **replicate** the general process locally:
+
+1. **Enable Development Mode** (if necessary to do dev tasks):
+ - Run the “Development Mode Toggle” workflow with `enable` or manually call `Set_Development_Mode.ps1`.
+
+2. **Run Unit Tests**:
+ - Confirm everything passes in your local environment.
+ - If you have custom or dev references, ensure Dev Mode is toggled appropriately.
+
+3. **Build VI Package**:
+ - Manually invoke `Build.ps1` from `pipeline/scripts` to generate a `.vip`.
+ - Pass optional metadata fields (e.g., `-CompanyName`, `-AuthorName`) if you want your build to be **branded**.
+ - On GitHub Actions, the workflow will produce and upload the artifact automatically.
+
+4. **Disable Dev Mode**:
+ - Revert to a normal LabVIEW environment so standard usage or testing can resume.
+
+---
+
+### 3.5 Example Developer Workflow
+
+**Scenario**: You want to implement a new feature, test it, and produce a **uniquely branded** `.vip`.
+
+1. **Enable Development Mode**:
+ - Either via the **Development Mode Toggle** workflow or `Set_Development_Mode.ps1`.
+
+2. **Implement & Test**:
+ - Use the **Run Unit Tests** workflow (or local script) to verify your changes pass.
+ - Keep Dev Mode enabled if needed for debugging; disable if you want a “clean” environment.
+
+3. **Open a Pull Request** and **Label** it:
+ - Assign `major`, `minor`, or `patch` to control the version bump.
+ - The CI will validate your code but *won’t* tag or release until merged.
+
+4. **Merge the PR** into `develop` (or `main`):
+ - The **Build VI Package & Release** workflow automatically tags the commit (e.g., `v1.2.0-build7`) and uploads the `.vip`.
+ - **Inside** that `.vip`, the fields for **“Company Name”** and **“Author Name (Person or Company)”** can reflect your **organization** or **repo**, ensuring it’s easy to identify which fork or team produced the build.
+
+5. **Disable Development Mode**:
+ - Switch LabVIEW back to normal mode.
+ - Optionally install the resulting `.vip` to confirm your new feature in a production-like environment.
+
+---
+
+## Final Notes
+
+- **Artifact Storage**: The `.vip` file is accessible under the Actions run summary (click “Artifacts”).
+- **Forking**: If another user forks your repo, the new **fork** sees GPG signing disabled automatically, preventing passphrase errors.
+- **Version Enforcement**: Pull requests without a version label default to `patch`; you can enforce labeling with an optional “Label Enforcer” step if desired.
+- **Branding**: To highlight the **organization** or **repository** behind a particular build, simply pass `-CompanyName` and `-AuthorName` (or similar parameters) into the `Build.ps1` script. This metadata flows into the final **Display Information** of the Icon Editor’s VI Package.
+
+By adopting these workflows—**Development Mode Toggle**, **Run Unit Tests**, and especially **Build VI Package & Release**—you can maintain a **streamlined, consistent** CI/CD process for the Icon Editor, while customizing the VI Package with your own **unique** or **fork-specific** branding.
diff --git a/docs/ci/actions/build-vi-package.md b/docs/ci/actions/build-vi-package.md
new file mode 100644
index 00000000..1db3169d
--- /dev/null
+++ b/docs/ci/actions/build-vi-package.md
@@ -0,0 +1,360 @@
+# **Introduction**
+
+This document is designed to help maintainers, contributors, and engineers automate the release process for LabVIEW-based projects—particularly the **Icon Editor**. By following this workflow, you can:
+
+- Incorporate **label-based semantic versioning** to increment major, minor, or patch numbers automatically.
+- Integrate a **commit-based build number** so each new commit naturally increases a “build” suffix (e.g., `-build42`).
+- Seamlessly **build** a `.vip` file and **publish** it through GitHub Actions, optionally attaching it to a release.
+- **Disable GPG signing** on forks, avoiding errors for contributors who lack the main repository’s signing keys.
+
+> Whether you’re merging a pull request, pushing hotfixes directly, or working on release branches with RC tags, this workflow unifies your entire packaging and release pipeline under a single YAML definition.
+
+
+# **Table of Contents**
+
+1. [1. Overview and Purpose](#1-overview-and-purpose)
+ - [1.1 What Problem Does This GitHub Action Solve?](#11-what-problem-does-this-github-action-solve)
+ - [1.2 Why Was It Created & Primary Function](#12-why-was-it-created--primary-function)
+ - [1.3 Intended Users](#13-intended-users)
+ - [1.4 High-Level Benefits](#14-high-level-benefits)
+2. [2. Environment & Requirements](#2-environment--requirements)
+ - [2.1 Supported Windows OS Versions](#21-supported-windows-os-versions)
+ - [2.2 Windows-Specific Prerequisites](#22-windows-specific-prerequisites)
+ - [2.3 Additional Software & Tools](#23-additional-software--tools)
+ - [2.4 Permissions & Credentials](#24-permissions--credentials)
+ - [2.5 Hardware/Performance Considerations](#25-hardwareperformance-considerations)
+3. [3. Action Configuration & Usage](#3-action-configuration--usage)
+ - [3.1 How the Action Is Triggered](#31-how-the-action-is-triggered)
+ - [3.2 Configurable Inputs / Parameters](#32-configurable-inputs--parameters)
+ - [3.3 Customization & Fork Setup](#33-customization--fork-setup)
+ - [3.4 Artifact Publication](#34-artifact-publication)
+4. [4. Workflow Details](#4-workflow-details)
+ - [4.1 Pipeline Overview](#41-pipeline-overview)
+ - [4.2 Version or Tagging Steps](#42-version-or-tagging-steps)
+ - [4.3 Pre-Release vs. Final Release](#43-pre-release-vs-final-release)
+
+
+
+## 1. **Overview and Purpose**
+
+### 1.1 What Problem Does This GitHub Action Solve?
+The **Build VI Package** workflow provides a **consistent, automated release process** for LabVIEW-based projects like the Icon Editor. Instead of manually labeling versions, packaging `.vip` artifacts, and drafting releases, this workflow:
+
+1. **Detects PR labels** (`major`, `minor`, `patch`) to decide version increments.
+2. Automatically **builds** a `.vip` file using a PowerShell script.
+3. Optionally **disables GPG signing** if the repo is a **fork**—avoiding errors from missing keys.
+4. **Pushes tags** and creates **GitHub Releases**, attaching the `.vip` artifact if desired.
+
+It eliminates confusion around versioning, keeps everything in one pipeline, and ensures every commit or merge triggers a reproducible build.
+
+### 1.2 Why Was It Created & Primary Function
+- **Why**:
+ - Old manual processes for releasing LabVIEW add-ons involved manually bumping versions, creating `.vip` files, and drafting GitHub releases by hand. This was prone to mistakes.
+- **Primary Function**:
+ - Offer a single, fork-friendly script that compiles the `.vip`, increments the version, and publishes a release.
+
+### 1.3 Intended Users
+- **Library Maintainers** needing reliable, standardized version increments.
+- **CI/CD Engineers** who want to embed LabVIEW packaging in a broader automation ecosystem.
+- **Fork Contributors** able to run the same workflow in their fork without GPG key issues.
+
+### 1.4 High-Level Benefits
+- **Label-Based Version Bumping**: Maintainers just add `major`, `minor`, or `patch` labels to the PR, no custom scripts needed.
+- **Commit-Based Build Number**: Every commit increments a “build” suffix, ensuring no collisions.
+- **Fork-Friendly**: If the repo name indicates it’s not the official one, GPG signing toggles off.
+- **Simplicity**: All steps—build, artifact upload, release creation—are in a single YAML file.
+
+
+
+## 2. **Environment & Requirements**
+
+### 2.1 Supported Windows OS Versions
+- Typically tested on **Windows Server 2019** or **2022** for self-hosted runners.
+- Any Windows environment hosting LabVIEW and `.NET` frameworks needed for your build scripts should suffice.
+
+### 2.2 Windows-Specific Prerequisites
+- **PowerShell 7+** recommended (since the script uses `pwsh`).
+- **LabVIEW** itself installed on the runner, including any **Application Builder** or modules required to build `.vip` files.
+- (Optional) Additional Windows components (like .NET or Visual Studio) if your pipeline references them.
+
+### 2.3 Additional Software & Tools
+- **Build Tools**: Some steps may call internal scripts (`Build.ps1`) that assume a certain LabVIEW version or environment.
+- **Chocolatey** or other package managers only if your script references them.
+- No `gh` CLI is strictly required—this workflow relies on `Invoke-RestMethod` for uploading release assets if needed.
+
+### 2.4 Permissions & Credentials
+- **contents: write**: The GITHUB_TOKEN must allow pushing tags and creating releases.
+- For **forks**, no special credentials are needed beyond GITHUB_TOKEN—if GPG is disabled, there’s no passphrase to worry about.
+
+### 2.5 Hardware/Performance Considerations
+- Building LabVIEW packages can be memory- and CPU-intensive. The runner should have enough resources for your largest builds (e.g., 4+ cores, 8GB+ RAM).
+- Disk space: Keep enough free space for intermediate build files.
+- If your build is slow or times out, consider caching or incremental builds.
+
+
+
+## 3. **Action Configuration & Usage**
+
+### 3.1 How the Action Is Triggered
+- **push**: On branches `main`, `develop`, `release/*`, `hotfix/*`.
+- **pull_request**: For PRs into those branches, so you can detect version labels.
+- **workflow_dispatch**: Maintainers can manually run from the Actions tab if needed (e.g., for a hotfix you want to re-release).
+
+### 3.2 Configurable Inputs / Parameters
+- **Environment Variables**:
+ - `DRAFT_RELEASE` (`true`/`false`): Are releases initially **draft**?
+ - `USE_AUTO_NOTES` (`true`/`false`): Use GitHub’s auto-generated release notes?
+ - `ATTACH_ARTIFACTS_TO_RELEASE` (`true`/`false`): Attach the `.vip` to the final release?
+ - `DISABLE_GPG_ON_FORKS` (`true`/`false`): If `true`, toggles off GPG signing for forks.
+- **PR Labels**: `major`, `minor`, `patch`, or none. If none, only the build number changes.
+
+### 3.3 Customization & Fork Setup
+- **Fork Setup**:
+ 1. **Copy** the workflow file (`.github/workflows/build-vi-package.yml`) into your fork.
+ 2. **Update** any references to the official repo name (`ni/labview-icon-editor`) if your fork is named differently.
+ 3. **Self-Hosted Runner**: Confirm your runner has the `iconeditor` label or update `runs-on` to match your runner’s labels.
+ 4. **Write Permissions**: In fork settings → Actions → General, ensure “Workflow Permissions” = “Read and write.”
+
+- **Overriding Defaults**:
+ - In your workflow’s `env:` block or job-level `env:`, you can set `DRAFT_RELEASE: false` if you want automatic publishing, or `ATTACH_ARTIFACTS_TO_RELEASE: true` to attach `.vip`.
+ - If you want GPG signing on your fork, set `DISABLE_GPG_ON_FORKS: false` (though you must provide keys).
+
+### 3.4 Artifact Publication
+- By default, the `.vip` is **uploaded** as an ephemeral artifact for that run.
+- If `ATTACH_ARTIFACTS_TO_RELEASE` is true, it’s also added to the GitHub Release under “Assets” so users can access it any time.
+
+
+
+## 4. **Workflow Details**
+
+### 4.1 Pipeline Overview
+
+1. **Disable GPG Signing (if Fork)**
+ - If `DISABLE_GPG_ON_FORKS == true` and `github.repository` doesn’t match the official repo name, the workflow sets `commit.gpgsign=false` and `tag.gpgsign=false`.
+ - Purpose: Avoid passphrase prompts or errors for fork maintainers without GPG keys.
+
+2. **Check Out & Full Clone**
+ - Uses `actions/checkout@v3` with `fetch-depth: 0` so we get the entire commit history (required for commit-based build number).
+
+3. **Determine Bump Type**
+ - On PR events, scans the PR labels: `major`, `minor`, `patch`, or defaults to `none`.
+ - If `none`, no version increment beyond the build number.
+
+4. **Commit-Based Build Number**
+ - We run `git rev-list --count HEAD`, storing the integer in `new_build_number`.
+ - This increments automatically with every commit, ensuring a unique build suffix like `-build37`.
+
+5. **Compute Final Version**
+ - Merges the label-based bump with existing tags (if any).
+ - If on `release/*` branch, appends a `-rc.` suffix.
+ - Always adds `-build` last, e.g. `v1.2.3-rc.5-build37`.
+
+6. **Build the Icon Editor VI Package**
+ - Calls a script (`Build.ps1`) that actually compiles LabVIEW code and produces a `.vip` file in `builds/VI Package/`.
+
+7. **Capture & Upload Artifacts**
+ - Finds the `.vip` in `builds/VI Package/`.
+ - Uploads it as an ephemeral artifact for the current Actions run.
+
+8. **Tag & Push**
+ - If it’s not a pull request event, creates an annotated tag (e.g., `v1.2.3-build37`) and pushes it to the remote.
+ - Requires `contents: write` permission for the `GITHUB_TOKEN`.
+
+9. **Create GitHub Release**
+ - If `DRAFT_RELEASE` is `true`, it’s a draft release. If `false`, publishes immediately.
+ - If `USE_AUTO_NOTES` is `true`, sets `generate_release_notes: true` for auto content.
+
+10. **Attach `.vip` to the Release** (if `ATTACH_ARTIFACTS_TO_RELEASE == true`)
+ - Uploads the `.vip` to the release’s “Assets” so it’s accessible even after ephemeral artifacts expire.
+
+11. **Re-Enable GPG** (if needed)
+ - If GPG was disabled, the Action restores the original commit/tag signing settings.
+
+### 4.2 Version or Tagging Steps
+
+- **`git describe --tags --abbrev=0`** or a custom pattern `v*.*.*-build*` might be used to find the last version tag.
+- If no prior tags, it defaults to `v0.0.0-build` (plus any suffix if `major/minor/patch` was used).
+
+### 4.3 Pre-Release vs. Final Release
+
+- **`release/*`** branches → Adds `-rc.` suffix to indicate pre-release.
+- Merging back to `main` typically yields a final version with no `-rc`.
+- If `draft_release` is `true`, maintainers can manually convert a draft release to a final one after verifying assets or notes.
+
+
+
+## 5. **Security & Permissions**
+
+### 5.1 Secure Data Handling
+1. **GITHUB_TOKEN**
+ - This workflow relies on GitHub’s ephemeral GITHUB_TOKEN, which needs enough scope to push tags and create releases (i.e., `contents: write`).
+ - Make sure your repository’s settings under **Actions** → **General** → **Workflow permissions** is set to **Read and write permissions**.
+
+2. **LabVIEW License & Keys**
+ - Your self-hosted runner must have a **validly licensed** copy of LabVIEW. If LabVIEW is not licensed or is missing required modules, the build might fail.
+ - If you choose to sign `.vip` or other files, ensure the runner has access to the appropriate certificates or GPG keys (if not disabling GPG on forks).
+
+3. **Fork Environments**
+ - If the repository is not the official `ni/labview-icon-editor`, and `DISABLE_GPG_ON_FORKS` is set to `true`, this workflow disables commit and tag signing.
+ - Without that toggle, a fork would often fail if it doesn’t have the correct signing keys available.
+
+4. **No Long-Term Secrets**
+ - By default, no additional secrets are stored. The ephemeral GITHUB_TOKEN is enough for standard tagging and release tasks.
+
+### 5.2 Permission Settings & Enforcement
+- If you use **branch or tag protection rules**, configure them so that the GitHub Actions token can create tags.
+- To allow auto-tagging on new versions:
+ 1. **Tag Creation** must not be blocked by your repo’s protection rules.
+ 2. For changes to the default branch (like `main`), ensure the Action can push if it’s set up with required status checks (or turn on “Allow GitHub Actions to bypass rules” in branch protections).
+
+### 5.3 Fork & Pull Request Security
+- For a public fork, limit your workflow’s scope if you worry about malicious PRs.
+- By default, secrets like `GITHUB_TOKEN` are available only in limited capacity on PRs from external repos.
+- GPG signing logic is automatically disabled for forks if you set `DISABLE_GPG_ON_FORKS` to `true`, preventing signing prompts or errors.
+
+
+
+## 6. **Maintenance & Administration**
+
+### 6.1 Keeping the Workflow Updated
+1. **Actions Versions**
+ - This workflow references certain actions, like `actions/checkout@v3` or `actions/github-script@v6`. Keep an eye on updates or deprecations.
+2. **Build.ps1**
+ - If your LabVIEW project evolves or you add steps, update the `Build.ps1` script accordingly.
+3. **Windows Runner Updates**
+ - Ensure your self-hosted runner OS is patched and has any new LabVIEW versions if your project updates.
+
+### 6.2 Runner Management
+- **Labels**: The workflow uses `runs-on: [self-hosted, iconeditor]`. Confirm your runner has both `self-hosted` and `iconeditor` labels.
+- **Resource Monitoring**: If the build is large or slow, upgrade the machine specs or add more runners to handle parallel tasks.
+
+### 6.3 Adding New Features
+- You can insert additional steps (e.g., unit tests, static analysis, doc generation) in the YAML. For instance, add a test step before building the `.vip`.
+- To do advanced alpha/beta channels, replicate the `release/*` logic with your own branch pattern (e.g., `release-alpha/*` => `-alpha.`).
+
+### 6.4 Delegating Workflow Administration
+- If multiple maintainers handle the Action:
+ 1. Document who can change the `.github/workflows/build-vi-package.yml` file.
+ 2. Decide if changes to the workflow require a PR review or certain status checks.
+
+
+
+## 7. **Usage & Examples**
+
+### 7.1 Pull Requests with Labels
+- **Scenario**: You create a PR from a feature branch into `develop`.
+- **Action**: Add a label like `major` or `minor`.
+- **Result**: Upon merging, the workflow updates that version field (major/minor/patch) plus applies a commit-based build number, then tags & releases.
+
+#### Example:
+1. PR labeled `minor`:
+ - Previous version: `v1.2.3-build45`
+ - New version on merge: `v1.3.0-build46`
+ - If it’s `release/*`, might become `v1.3.0-rc.1-build46`.
+
+### 7.2 Direct Push to Main or Develop
+- **Scenario**: You quickly push a fix to `develop` without a PR label.
+- **Action**: The workflow sees no label, so major/minor/patch remain unchanged. The build number increments automatically.
+- **Result**: The new tag might go from `v1.2.3-build46` → `v1.2.3-build47`.
+
+### 7.3 Working on a Release Branch
+- **Scenario**: You branch off `release/1.2`.
+- **Action**: The workflow appends `-rc.` each time you commit to that release branch, e.g. `v1.2.0-rc.2-build50`.
+- **Result**: Merging `release/1.2` back to `main` finalizes `v1.2.0-build51`.
+
+### 7.4 Manually Triggering (workflow_dispatch)
+- **Scenario**: A maintainer manually runs the workflow from the Actions tab (if enabled).
+- **Action**: Provide any input parameters (if configured), or rely on defaults like `none` for version bump.
+- **Result**: The script runs as if it were a push event, producing a tag & release if not a PR context.
+
+
+
+## 8. **Testing & Verification**
+
+
+
+### 8.1 Fork Testing
+1. **Fork the Repo**: Copy `.github/workflows/build-vi-package.yml` to your fork.
+2. **Push Changes**: Create or modify a branch in your fork.
+3. **Open PR (optional)**: If you label it, watch the logs to see if the version increments properly.
+4. **Check the Release**: Ensure a `.vip` file is built, ephemeral artifact is uploaded, and if `ATTACH_ARTIFACTS_TO_RELEASE=true`, it’s attached to your fork’s release assets.
+
+### 8.2 Main Repo Testing
+1. Merge a labeled PR (e.g., `patch`) into `develop`.
+2. Observe the workflow’s console output: the version should increment patch by 1, and the build number increments from commit count.
+3. Confirm a new tag & release appear in your main repository’s release list.
+
+### 8.3 LabVIEW-Specific QA
+- If you have LabVIEW unit tests, integrate them by adding a step in the YAML:
+ ```yaml
+ - name: Run LabVIEW Tests
+ shell: pwsh
+ run: .\pipeline\scripts\TestLabVIEW.ps1
+ ```
+- Ensure they pass before building the `.vip`. If they fail, the script can exit with a non-zero code, stopping the release.
+
+### 8.4 Checking GPG Toggle
+- If your fork is named differently (e.g., `username/lv-icon-fork`), confirm `DISABLE_GPG_ON_FORKS=true` toggles off commit/tag signing. Look for a step titled “Possibly disable GPG signing on forks” in your logs.
+
+
+## 9. **Troubleshooting**
+
+### 9.1 Common Error Scenarios
+
+1. **No .vip Found**
+ - Likely your `Build.ps1` didn’t place the artifact in `builds/VI Package/`.
+ - Check script logs or the step that locates `.vip`.
+
+2. **Invalid URI** or “Hostname could not be parsed”
+ - The `upload_url` from `createRelease` might still contain `{?name,label}`. The workflow typically splits on `{`, but if that fails, ensure the code properly strips it out before appending `?name=`.
+
+3. **Permission Errors Pushing Tag**
+ - The GITHUB_TOKEN needs `contents: write` permission.
+ - If your repo or organization uses tag protection, allow GitHub Actions to create tags.
+
+4. **LabVIEW Licensing Failure**
+ - The self-hosted runner might not have a proper LabVIEW license or is missing required toolkits.
+ - Check LabVIEW logs or ensure you’ve got the correct environment on that machine.
+
+### 9.2 Debugging Tips
+- **Enable -Verbose** in the script calls, capturing detailed logs.
+- **Check Self-Hosted Runner Logs** on Windows in `%UserProfile%\.runner\` or wherever your runner is installed.
+- **Local Testing**: Try running the same powershell commands locally on a dev environment.
+
+### 9.3 Where to Seek Help
+- For general build or GPG issues, consult NI or LabVIEW community forums.
+- For GitHub Actions or workflow YAML syntax, check official GitHub Docs or open an issue on your repo.
+
+
+
+## 10. **FAQ**
+
+**Q:** *How do I force a “patch” bump if I push directly to develop?*
+**A:** You can edit the “Determine bump type” step to default to `patch` instead of `none` if no label is found.
+
+**Q:** *What if I want a final release immediately, without draft mode?*
+**A:** Set `DRAFT_RELEASE: false`. Then your release is published the moment the workflow completes.
+
+**Q:** *Can I skip attaching `.vip` to the release but keep ephemeral artifacts?*
+**A:** Yes, keep `ATTACH_ARTIFACTS_TO_RELEASE: false` while the ephemeral artifact upload remains by default.
+
+**Q:** *Do I still need to manually publish the release if it’s a pre-release?*
+**A:** If `DRAFT_RELEASE` is true, you’ll need to “publish” it from draft. If it’s a `-rc` suffix, that’s just a naming convention, but you can finalize or remove that suffix in a subsequent version.
+
+**Q:** How do I override build number or forcibly skip a release?
+**A:** By default, we rely on `git rev-list --count HEAD`. You can change it by passing a custom environment variable or skipping the tag steps.
+
+**Q:** Does it support alpha/beta channels out of the box?
+**A:** You can parse more branch patterns (e.g. `release-alpha/*`) and set a suffix like `-alpha.`. The logic is easily adapted in the “Compute version string” step.
+
+**Q:** What about manual triggers?
+**A:** If `workflow_dispatch` is enabled, you can run it from the Actions tab, typically defaulting to the same logic (`none` for bump).
+
+**Q:** Where do I see ephemeral artifacts?
+**A:** In the Actions run logs. Look for the “Artifacts” section. If you attach the `.vip` to the release, it’s permanent under “Assets” in the Release page.
+
+## 11. **Conclusion**
+
+By properly setting up environment variables, referencing your LabVIEW environment on a self-hosted runner, and using label-based version increments plus a commit-based build number, this GitHub Action automates your entire `.vip` build and release pipeline. Fork owners can disable GPG signing, and maintainers can easily control draft vs. published releases and whether the artifact is attached. Follow the troubleshooting steps if anything goes awry, and enjoy streamlined LabVIEW CI/CD!
+
+
diff --git a/docs/ci/actions/development-mode-toggle.md b/docs/ci/actions/development-mode-toggle.md
new file mode 100644
index 00000000..5e9365cc
--- /dev/null
+++ b/docs/ci/actions/development-mode-toggle.md
@@ -0,0 +1,128 @@
+# Development Mode Toggle
+
+This document explains how to use and customize the **Development Mode Toggle** workflow, which lets you enable or disable a “development mode” on a self-hosted GitHub Actions runner. It is particularly aimed at developers contributing to NI’s (National Instruments) LabVIEW-based open-source projects.
+
+## 1. Overview
+
+### What Is “Development Mode”?
+In LabVIEW-centric projects, “development mode” usually refers to a runner state that enables additional debugging or specialized project setup. For instance, you might need to move specific set of files from Program Files, or set a Token on the LabVIEW.ini of a specific LabVIEW version before running your workflow. Turning “dev mode” on/off allows you to toggle these specialized settings quickly in order to switch your system to a state where you can install the VI Package in order to test your change and to distribute it for others to test as well.
+
+### Purpose of This Workflow
+- Makes it easy for collaborators to set a **self-hosted runner** (their own machine or a shared one) to a special “development” state without having to do it manually, taking into consideration that this will have to happen multiple times in the development phase.
+- Can be triggered manually (via `workflow_dispatch`) or from other workflows (via `workflow_call`).
+- Lets you quickly switch back to a **testable** state when you’re done coding so you can install the final VI Package to test your change.
+- Allows collaborators to **experiment with or update the order of operations** in the underlying PowerShell scripts on their own fork, then propose those changes via pull requests if they happen to improve our overall process.
+
+**Note**: Contributors who fork this repository can keep their local copy of `.github/workflows/toggle-dev-mode.yml` and its associated PowerShell scripts up to date by frequently pulling changes from the upstream repository. Likewise, if they make improvements to the scripts in their fork, they can open a pull request to merge those improvements back upstream.
+
+## 2. Usage
+
+You do **not** need to copy/paste the entire workflow snippet here, as it’s already in your repo (“Development mode toggle”). Instead, here is a conceptual usage overview:
+
+1. **Triggering Manually**
+ - Go to the “Actions” tab on your (or your fork’s) GitHub repository.
+ - Select the **“Toggle Development Mode”** workflow.
+ - Click “Run workflow” and choose either `enable` or `disable` from the dropdown.
+ - This will execute the PowerShell scripts (`Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1`) on the **target self-hosted runner** (your personal machine or a shared machine).
+
+2. **Important Note for Testing**
+ - If your system is set to dev mode (`enable`), you wont be able to open the icon editor after you install the VI Package.
+ - **Once you finish coding** or making changes, **switch back** (`disable`) to a normal testable state to be able to install the VI Package and test your change.
+
+3. **Triggering from Another Workflow**
+ - Use a `workflow_call` reference (detailed examples below).
+ - Pass the input parameter `mode` set to `enable` or `disable`.
+ - The runner that calls it will be the one switched into (or out of) dev mode.
+
+## 3. Examples: Calling This Workflow
+
+Below are **three** ways to invoke this workflow. Each approach sets `mode` to either `enable` or `disable`.
+
+### 3.1 Call from Another Workflow in the Same Repository
+
+If you have another workflow file (e.g., `my-other-workflow.yml`) in the same repo, you can reference “Development mode toggle” by its local path:
+
+ # my-other-workflow.yml
+ name: "My Other Workflow"
+
+ on:
+ workflow_dispatch:
+
+ jobs:
+ call-dev-mode:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Invoke Dev Mode Toggle (enable)
+ uses: ./.github/workflows/toggle-dev-mode.yml
+ with:
+ mode: enable
+
+1. `uses: ./.github/workflows/toggle-dev-mode.yml` – Tells GitHub to run a local reusable workflow found in your repo.
+2. `with:` – Passes inputs to that workflow. Here, `mode: enable`.
+
+### 3.2 Call from Another Repository (Direct GitHub Reference)
+
+If you store “Development mode toggle” in a separate public repo, you can reference it by the GitHub org/repo and the specific path/branch:
+
+ name: "Cross-Repo Dev Mode Toggle"
+
+ on:
+ workflow_dispatch:
+
+ jobs:
+ remote-dev-mode:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Use remote Dev Mode Toggle
+ uses: //.github/workflows/toggle-dev-mode.yml@main
+ with:
+ mode: disable
+
+1. Replace `/` with the actual GitHub account and repository name (for example, `ni/my-shared-workflows`).
+2. The suffix `@main` indicates which branch/ref to fetch. You can also use a tag or commit SHA.
+3. Inputs like `mode` are passed the same way.
+
+### 3.3 Call from a Fork
+
+If a collaborator forked your original repo, they might keep the workflow in their own fork. They can reference that fork directly:
+
+ name: "Forked Dev Mode Example"
+
+ on:
+ workflow_dispatch:
+
+ jobs:
+ forked-workflow-call:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Call Dev Mode Toggle from My Fork
+ uses: //.github/workflows/toggle-dev-mode.yml@my-feature-branch
+ with:
+ mode: enable
+
+Here, you might see something like `githubuser/labview-icon-editor-fork/.github/workflows/toggle-dev-mode.yml@feature-xyz`. Again, you pass the `mode` input as needed. Whenever upstream changes are made to the scripts, the fork owner can **pull** to update their local `.github/workflows/toggle-dev-mode.yml` file.
+
+---
+
+## 4. Customization
+
+All “dev mode” logic resides in two PowerShell scripts:
+
+- **`Set_Development_Mode.ps1`** – Called when mode is `enable`.
+- **`RevertDevelopmentMode.ps1`** – Called when mode is `disable`.
+
+These scripts currently do things like update environment variables, configure LabVIEW paths, or install certain dependencies. **To change** how “dev mode” behaves, **edit those scripts** directly.
+
+### Pull Requests with Script Updates
+Collaborators are free to:
+1. **Modify** `Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1` on their forks.
+2. **Enable dev mode** on their self-hosted runner (via their fork), capturing the GitHub Actions logs as proof that their changes worked as intended.
+3. **Open a Pull Request** to merge these script changes back into the upstream repository, referencing the successful action logs as additional evidence.
+
+---
+
+## 5. Additional Resources
+- Refer to your README.md for details on setting up your runner (LabVIEW requirements, etc.).
+- GitHub Docs: https://docs.github.com/en/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow
+
+---
diff --git a/docs/ci/actions/maintainers-guide.md b/docs/ci/actions/maintainers-guide.md
new file mode 100644
index 00000000..c2280f76
--- /dev/null
+++ b/docs/ci/actions/maintainers-guide.md
@@ -0,0 +1,175 @@
+# Validated Experiment Maintainers’ Guide
+
+Below is a fully validated version of your markdown document, with corrected anchors so that each Table of Contents link will jump to the correct subsection on GitHub. You can copy/paste this as-is into a `.md` file.
+
+---
+
+## Introduction
+This document is written for maintainers of experimental branches and experiment leads in order to guide them throughout the lifecycle of the experiment. It covers:
+
+- **How** to create and manage experimental branches,
+- **When** and **how** to manually approve `.vip` artifact distribution,
+- **Working** with the Steering Committee for final merges,
+- **Handling** partial merges, alpha/beta/rc sub-branches, and BDFL overrides.
+
+**Context**: Our project supports a **GitFlow-like model** for core development (`main`, `develop`, `release-*`, `hotfix/*`) plus **long-lived experimental branches** (`experiment/`). This doc focuses on the extra tasks maintainers handle for experiments.
+
+> **Note**: For a broader overview of experiment lifecycle, see [EXPERIMENTS.md](../experiments.md). For governance details (Steering Committee roles, BDFL approach), see [GOVERNANCE.md](./GOVERNANCE.md). For common pitfalls in experiments, see [TROUBLESHOOTING_EXPERIMENTS.md](./troubleshooting-experiments.md).
+
+---
+
+## Table of Contents
+1. [Roles & Responsibilities](#roles--responsibilities)
+2. [Creating an Experiment Branch](#creating-an-experiment-branch)
+3. [Approving Official Artifact Distribution](#approving-official-artifact-distribution)
+4. [Alpha/Beta/RC Management](#alpha-beta-rc-management)
+5. [Code Scanning & Security Checks](#code-scanning--security-checks)
+6. [BDFL Overrides](#bdfl-overrides)
+7. [Labels & Final Merges](#labels--final-merges)
+8. [Partial Merges](#partial-merges)
+9. [Archiving or Deleting an Experiment](#archiving-or-deleting-an-experiment)
+10. [Best Practices & Tips](#best-practices--tips)
+11. [See Also](#see-also)
+
+---
+
+## Roles & Responsibilities
+Maintainers serve as **administrators** and **trusted gatekeepers**. You:
+
+- **Facilitate** the creation of `experiment/` branches once the Steering Committee approves a new experiment.
+- **Oversee** day-to-day merges in the experiment if you’re also designated as the “experiment lead,” or support the lead if they’re external.
+- **Enforce** scanning and manual approval before distributing `.vip` artifacts from experimental branches.
+- **Coordinate** final merges into `develop` (and eventually `main`) for big features.
+
+The **Open Source Program Manager** (OSPM) or designated NI staff typically handle BDFL decisions and can override specific steps on a case-by-case basis (see [BDFL Overrides](#bdfl-overrides)).
+
+---
+
+## Creating an Experiment Branch
+1. **Steering Committee Approval**
+ - A collaborator or lead opens a GitHub Issue proposing the experiment. The Steering Committee, chaired by the OSPM, decides if it’s viable.
+2. **Branch Creation**
+ - You (an NI maintainer) create `experiment/` from `develop`.
+ - By default, this branch has “NoCI” for `.vip` distribution to **prevent** automatic artifact sharing until code scanning is done.
+3. **Documenting**
+ - Add a short summary on the new branch in the GitHub Issue so watchers know it’s live.
+ - If alpha/beta/rc sub-branches are planned, note that too.
+
+**Pro Tip**: If the experiment lead is external but has repo write access, you can coordinate with them to create the branch. The key is ensuring official distribution remains blocked initially until approval.
+
+---
+
+## Approving Official Artifact Distribution
+Until you **manually** approve the experiment, the specialized CI or GitHub Action **won’t** publish `.vip` artifacts.
+
+### How to Approve
+1. **Workflow Dispatch**
+ - Go to the **Actions** tab on GitHub, locate the “approve-experiment” workflow (or similarly named).
+ - Click **“Run workflow”**, specifying the `experiment/` branch if needed.
+ - This sets an environment variable or label (e.g., “ApprovedCI”) that flips the build steps from “NoCI” → “ApprovedCI.”
+2. **Verification**
+ - Confirm the logs show “ApprovedCI” is now active. Subsequent commits or merges in the experiment will produce `.vip` artifacts for testers.
+
+### When to Approve
+- Typically **after** Docker VI Analyzer + CodeQL show no critical warnings.
+- The experiment lead (or Steering Committee) may nudge you once they feel the code is stable enough to share widely.
+
+**Note**: If the experiment changes drastically or code scanning flags new issues, you can revert to “NoCI” or temporarily stop artifact distribution.
+
+---
+
+## Alpha Beta RC Management
+Some experiments use **sub-branches** to stage progress:
+
+1. **Alpha**
+ - For early prototypes, possibly unstable.
+ - Merges from alpha → main experiment branch once it’s somewhat stable.
+2. **Beta**
+ - After alpha is proven, create a `experiment//beta` for broader internal testing.
+ - PR merges from beta → the main experiment branch bring more maturity to the code.
+3. **RC (Release Candidate)**
+ - Near-final code. Merging rc → the main experiment branch typically signals readiness for integration into `develop`.
+
+**Maintainer Role**
+- You ensure sub-branches are protected or open for the right collaborators.
+- Provide guidance on labeling merges (“merge alpha → main experiment,” etc.) using the specialized GitHub Action that logs recommended commands.
+
+---
+
+## Code Scanning & Security Checks
+**Docker VI Analyzer** and **CodeQL** run automatically:
+
+1. **Check Logs**
+ - Each PR or push will display results. If issues are flagged, ask the experiment lead to address them before approving `.vip` builds.
+2. **Failure Cases**
+ - If repeated critical warnings appear, you might keep the experiment in “NoCI” until resolved.
+ - The BDFL or OSPM can override if it’s a priority.
+
+> **Note**: This scanning approach is still being experimented with by LabVIEW R&D, so occasional false positives or integration quirks may occur. See `TROUBLESHOOTING_EXPERIMENTS.md` for more info.
+
+---
+
+## BDFL Overrides
+Although we want a consistent approach, the BDFL (via the OSPM or designated NI staff) may **skip** certain steps in **rare** circumstances:
+
+- **Forcing** a `.vip` artifact distribution even if scanning isn’t fully complete.
+- **Ignoring** normal labeling or merging rules in urgent cases (e.g., critical fixes).
+
+We don’t document formal guidelines for these rare actions; they’re done case by case. If you see a forced override, log it in the relevant GitHub Issue or PR for transparency.
+
+---
+
+## Labels & Final Merges
+### Labels for Major/Minor/Patch
+The main CI doc covers how to label PRs. Generally:
+- “major” = big changes
+- “minor” = moderate addition
+- “patch” = bug fix
+
+### Merging Experiment → `develop`
+Once an experiment is ready for prime time:
+1. **Open a PR** from `experiment/` (or its `rc` branch) to `develop`.
+2. **Steering Committee** decides if it’s major/minor/patch for the next release.
+3. Maintainers just ensure the right label is set, then merge.
+
+*(For partial merges, see below.)*
+
+---
+
+## Partial Merges
+If only a portion of the experiment is viable:
+
+1. **Create a Sub-Branch**
+ - For instance, `experiment/-partial`, cherry-picking or selecting commits that are stable.
+2. **Open a PR** from that sub-branch into `develop`.
+3. **Continue** other incomplete features in the main experiment branch if it’s still ongoing.
+
+---
+
+## Archiving or Deleting an Experiment
+If an experiment is **complete** or **abandoned**:
+
+- **Complete**: Merge to `develop`, then delete or rename the branch to `archived/`.
+- **Abandoned**: If scanning fails repeatedly or scope changes drastically, you can delete or archive it.
+- Document the reason in the original GitHub Issue.
+
+---
+
+## Best Practices & Tips
+1. **Frequent Merges from `develop`**
+ - Minimizes massive conflicts. At least once every couple of weeks if `develop` is active.
+2. **Early “approve-experiment”**
+ - If you trust the scanning results quickly, enabling `.vip` distribution sooner can help gather feedback from collaborators.
+3. **Communicate with the Steering Committee**
+ - Keep them informed of major changes, alpha/beta milestones, or partial merges.
+4. **Log BDFL Overrides**
+ - If an override happens, mention it in the PR or Issue to maintain transparency.
+
+---
+
+## See Also
+- [EXPERIMENTS.md](../experiments.md)
+- [TROUBLESHOOTING_EXPERIMENTS.md](./troubleshooting-experiments.md)
+- GOVERNANCE.md (in progress)
+
+---
diff --git a/docs/ci/actions/multichannel-release-workflow.md b/docs/ci/actions/multichannel-release-workflow.md
new file mode 100644
index 00000000..c98547a3
--- /dev/null
+++ b/docs/ci/actions/multichannel-release-workflow.md
@@ -0,0 +1,210 @@
+# **Updated Guide: Multi-Channel Release Workflow**
+
+This revised guide focuses on the **release workflow**, specifically how we handle **multiple pre-release channels** (Alpha, Beta, RC) in addition to final versions.
+
+
+## **Table of Contents**
+
+1. [Overview & Purpose](#overview--purpose)
+2. [Requirements & Environment](#requirements--environment)
+3. [Configuration & Branch Patterns](#configuration--branch-patterns)
+4. [Workflow Steps](#workflow-steps)
+ - [Disable GPG on Forks](#disable-gpg-on-forks)
+ - [Fetch & Determine Version](#fetch--determine-version)
+ - [Build & Artifact Handling](#build--artifact-handling)
+ - [Tag & Release Creation](#tag--release-creation)
+5. [Multiple Pre-Release Channels Explained](#multiple-pre-release-channels-explained)
+ - [Branch Name Conventions](#branch-name-conventions)
+ - [Alpha / Beta / RC Logic](#alpha--beta--rc-logic)
+ - [Final Release Flow](#final-release-flow)
+6. [Usage Examples](#usage-examples)
+7. [Troubleshooting & Tips](#troubleshooting--tips)
+8. [FAQ](#faq)
+9. [Conclusion](#conclusion)
+
+
+
+## **1. Overview & Purpose**
+
+This **Multi-Channel Release Workflow** automates the packaging and releasing of LabVIEW `.vip` files. It:
+
+- Uses **label-based** semantic version increments for major/minor/patch.
+- Maintains a **commit-based build number**, so every new commit yields a unique suffix (`-buildNN`).
+- Extends pre-release logic to **Alpha**, **Beta**, and **RC** channels, not just a single `release/*` for RC.
+- Optionally **disables GPG** signing if the repository is a fork.
+
+By adopting these patterns, maintainers can run alpha, beta, and RC pipelines in parallel or sequentially, each channel generating distinct pre-release versions.
+
+
+
+## **2. Requirements & Environment**
+
+1. **Windows Self-Hosted Runner**
+ - LabVIEW installed to build `.vip` files.
+ - PowerShell 7+ recommended.
+
+2. **Repository Permissions**
+ - The GitHub Actions token (`GITHUB_TOKEN`) needs `contents: write` to push tags & create releases.
+ - If you have branch protection on tags, allow actions to create them.
+
+3. **Labels**
+ - Pull requests must use `major`, `minor`, or `patch` to increment those fields. If no label, only the build number increments.
+
+4. **Fork Considerations**
+ - If `DISABLE_GPG_ON_FORKS == true`, the workflow sets `commit.gpgsign` and `tag.gpgsign` to `false` for forks (i.e., if the `github.repository` is not your official name).
+
+
+
+## **3. Configuration & Branch Patterns**
+
+1. **Alpha**
+ - Branch pattern: `release-alpha/*`.
+ - Produces versions like `vX.Y.Z-alpha.-build`.
+2. **Beta**
+ - Branch pattern: `release-beta/*`.
+ - Produces `vX.Y.Z-beta.-build`.
+3. **RC**
+ - Branch pattern: `release-rc/*`.
+ - Produces `vX.Y.Z-rc.-build`.
+4. **Other Branches**
+ - `main`, `develop`, `hotfix/*` produce final releases with no alpha/beta/rc suffix.
+ - No label => major/minor/patch remain unchanged; build increments only.
+
+Use whichever patterns best fit your project’s branching model. If you prefer subdirectories (`release/alpha/*` vs. `release-alpha/*`), adapt the snippet accordingly.
+
+
+
+## **4. Workflow Steps**
+
+Below is a **high-level** breakdown. In your `.github/workflows/build-vi-package.yml`, these steps typically appear in order:
+
+
+### **Disable GPG on Forks**
+- If `DISABLE_GPG_ON_FORKS == true` and the repo name doesn’t match your official repository, sets:
+ ```powershell
+ git config --global commit.gpgsign false
+ git config --global tag.gpgsign false
+ ```
+- Captures the old values to restore them later.
+
+
+### **Fetch & Determine Version**
+1. **Check out** the repo with `fetch-depth: 0` to have full commit history.
+2. **Determine bump type** by reading PR labels (`major`, `minor`, `patch`, or `none`).
+3. **Build number** = total commits (`git rev-list --count HEAD`).
+4. **Compute final version**:
+ - Parse the last stable tag (or default to `v0.0.0`).
+ - Apply major/minor/patch if needed.
+ - If branch matches `release-alpha/*`, `release-beta/*`, or `release-rc/*`, append `-alpha.`, `-beta.`, or `-rc.`.
+ - Finally append `-build`.
+
+
+### **Build & Artifact Handling**
+- Calls a `Build.ps1` script that compiles LabVIEW code and outputs `.vip` to `builds/VI Package/*.vip`.
+- Uploads the `.vip` as an ephemeral artifact with `actions/upload-artifact@v4`.
+
+
+### **Tag & Release Creation**
+- If event is *not* `pull_request`, we:
+ 1. Create an annotated tag → `vX.Y.Z-etc.`
+ 2. Push the tag to origin.
+ 3. Create a GitHub release. If the version is alpha/beta/rc, set `prerelease: true`.
+ 4. If `ATTACH_ARTIFACTS_TO_RELEASE == true`, attach the `.vip` to the release using `Invoke-RestMethod`.
+
+
+
+## **5. Multiple Pre-Release Channels Explained**
+
+
+### **5.1 Branch Name Conventions**
+- **Alpha**: `release-alpha/1.0`, `release-alpha/mynewfeature`, etc.
+- **Beta**: `release-beta/2.0`, `release-beta/test`, etc.
+- **RC**: `release-rc/2.1`, `release-rc/final-stability`.
+
+Any commit to these branches triggers an alpha/beta/rc suffix. Merging to `main` finalizes the version (suffix removed).
+
+
+### **5.2 Alpha / Beta / RC Logic**
+1. We parse branch name for patterns like:
+ ```powershell
+ if ($branchName -like 'release-alpha/*') {
+ $preSuffix = "alpha.$commitsCount"
+ }
+ elseif ($branchName -like 'release-beta/*') {
+ $preSuffix = "beta.$commitsCount"
+ }
+ elseif ($branchName -like 'release-rc/*') {
+ $preSuffix = "rc.$commitsCount"
+ }
+ else {
+ $preSuffix = ""
+ }
+ ```
+2. If `$preSuffix` is non-empty, `isPrerelease = true`.
+3. Final version: `v..--build`.
+
+
+### **5.3 Final Release Flow**
+- If branch doesn’t match alpha/beta/rc patterns, `$preSuffix` is empty.
+- `isPrerelease = false`, resulting in a stable release, e.g. `v1.3.4-build50`.
+
+
+
+## **6. Usage Examples**
+
+1. **Alpha Channel Testing**
+ - You want an early test for version 2.0: create `release-alpha/2.0`.
+ - Each commit produces something like `v2.0.0-alpha.2-build41`.
+ - Merging alpha → beta or main finalizes or transitions the channel.
+
+2. **Beta Channel**
+ - `release-beta/2.0`. Now each commit yields `v2.0.0-beta.3-build45`.
+ - Merging back to `main` yields a stable `v2.0.0-build46`.
+
+3. **RC Branch**
+ - `release-rc/2.1`. The workflow sets `-rc.` so your testers see it’s near final.
+ - Merging to main ends the RC, resulting in `v2.1.0-buildXX`.
+
+4. **No Pre-Release**
+ - If on `develop` or `main` directly, no suffix is appended, e.g. `v1.2.3-build22`.
+
+
+
+## **7. Troubleshooting & Tips**
+
+1. **Branch Name Misspellings**
+ - If you name `release-apha/*` (typo in “alpha”), the script won’t detect alpha. Ensure consistent naming.
+
+2. **Overlapping Patterns**
+ - If your branch name inadvertently matches more than one pattern, the first `if` wins. Keep patterns distinct.
+
+3. **Auto Notes**
+ - If `USE_AUTO_NOTES == true`, you get auto-generated release notes for alpha/beta/rc. Manually finalize them if you prefer.
+
+4. **Final Merge**
+ - Typically, you merge alpha → beta → rc → main in sequence, each step dropping the old suffix for the new. If you do “hotfix” merges or skip channels, ensure you keep version consistency.
+
+5. **Same Bump Type**
+ - The label-based bump is orthogonal to alpha/beta/rc. If no label is set, major/minor/patch remain the same, but you might still produce `-alpha.-buildXX`.
+
+
+
+## **8. FAQ**
+
+**Q1**: *Can I have alpha, beta, rc all in one folder, like `release/alpha/*`, `release/beta/*`?*
+**A1**: Yes, just adapt the pattern checks, e.g. `$branchName -like 'release/alpha/*'`, `$branchName -like 'release/beta/*'`, etc.
+
+**Q2**: *What if I want numeric channel IDs, e.g. `-alpha2` instead of `-alpha.2`?*
+**A2**: You can build `$preSuffix = "alpha$commitsCount"`—just remove the dot.
+
+**Q3**: *Does GitHub auto-flag alpha or beta suffix releases as pre-release?*
+**A3**: Not automatically. We set `prerelease: true` if `$preSuffix` is non-empty. This ensures the release is marked pre-release in GitHub’s UI.
+
+**Q4**: *How do I integrate these channels with tagging older versions or skipping certain channels?*
+**A4**: You can skip alpha or beta if you like, or go from `develop` → `release-alpha/*` → `release-rc/*` → `main`. The workflow logic is flexible.
+
+
+
+## **9. Conclusion**
+
+By supporting **multiple pre-release channels** (Alpha, Beta, RC), this updated release workflow offers greater flexibility for iterative testing stages. Each branch pattern yields a distinct suffix (`-alpha.`, `-beta.`, or `-rc.`). Merging into a final branch (e.g., `main`) produces a stable release with no suffix, but still uses **commit-based** build numbering. Combined with label-based major/minor/patch increments, you have a **robust**, **fork-friendly**, and **multi-stage** CI/CD pipeline for LabVIEW.
diff --git a/docs/ci/actions/runner-setup-guide.md b/docs/ci/actions/runner-setup-guide.md
new file mode 100644
index 00000000..0ee9f2dc
--- /dev/null
+++ b/docs/ci/actions/runner-setup-guide.md
@@ -0,0 +1,169 @@
+# Runner Setup Guide
+
+This document explains how to locally set up and run the **LabVIEW Icon Editor** workflows on a **self-hosted runner** using **GitHub Actions**.
+
+## Table of Contents
+
+1. [Introduction](#introduction)
+2. [Quickstart](#quickstart)
+3. [Detailed Guide](#detailed-guide)
+ 1. [Development vs. Testing](#development-vs-testing)
+ 2. [Available GitHub Actions](#available-github-actions)
+ 3. [Setting Up a Self-Hosted Runner](#setting-up-a-self-hosted-runner)
+ 4. [Running the Actions Locally](#running-the-actions-locally)
+ 5. [Example Developer Workflow](#example-developer-workflow)
+4. [Next Steps](#next-steps)
+
+
+## 1. Introduction
+
+This document details how to automate **building**, **testing**, and **packaging** the **LabVIEW Icon Editor** on **Windows** using **GitHub Actions** on a **self-hosted runner**. By employing these workflows, you can:
+
+- **Eliminate** manual tasks like editing `vi.lib` or toggling `labview.ini`.
+- **Run** consistent builds and tests across different machines or developers.
+- **Automatically version** your Icon Editor code via **semantic labeling** (major/minor/patch) plus a global build counter.
+- **Attach** `.vip` artifacts to a new GitHub Release (unless it’s a pull request).
+- Seamlessly handle **fork** scenarios—**GPG signing** is enabled if `github.repository` is your main repo, disabled otherwise.
+
+Additionally, **you can pass metadata fields** (like **organization** or **repository name**) to the **build script**. These fields are embedded into the **VI Package** display information, effectively **branding** the Icon Editor package with a unique identifier. This is especially useful when multiple forks or organizations produce their own versions of the Icon Editor—ensuring each `.vip` is clearly labeled with the correct “author” or “company.”
+
+> **Prerequisites**:
+> - **LabVIEW 2021 SP1 (32-bit and 64-bit)** both required.
+> - The relevant **VIPC** file is now at `Tooling/deployment/runner_dependencies.vipc`.
+> - [PowerShell 7+](https://github.com/PowerShell/PowerShell/releases/latest)
+> - [Git for Windows](https://github.com/git-for-windows/git/releases/latest)
+
+
+## 2. Quickstart
+
+**For experienced users**, a brief overview:
+
+1. **Install Required Software**
+ - Ensure both **LabVIEW 2021 SP1 32-bit and 64-bit** are installed.
+ - [PowerShell 7+](https://github.com/PowerShell/PowerShell/releases/latest)
+ - [Git for Windows](https://github.com/git-for-windows/git/releases/latest)
+
+2. **Apply the VIPC (optional)**
+ - If your environment needs certain dependencies, **apply** `Tooling/deployment/runner_dependencies.vipc` in both 32-bit and 64-bit LabVIEW 2021 SP1.
+
+3. **Configure a Self-Hosted Runner**
+ - Go to **Settings → Actions → Runners** in your (forked) repo.
+ - Follow GitHub’s steps to add a Windows runner.
+
+4. **Development Mode Toggle**
+ - (Optional) Toggle LabVIEW dev mode (`Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1`) via the **Development Mode Toggle** workflow.
+
+5. **Run Unit Tests**
+ - Use the **Run Unit Tests** workflow to confirm environment health.
+
+6. **Build VI Package**
+ - Invoke **Build VI Package & Release** to produce `.vip`, automatically version your code (labels vs. default patch), and optionally create a GitHub Release.
+ - **You can also** pass in **org/repository** info (e.g., `-CompanyName "MyOrg"` or `-AuthorName "myorg/myrepo"`) to brand the resulting package with your unique identifiers.
+
+7. **Disable Dev Mode** (Optional)
+ - Revert environment once building/testing is done.
+
+
+
+## 3. Detailed Guide
+
+
+### 1. Development vs. Testing
+
+**Development Mode**
+- Temporarily reconfigures `labview.ini` and `vi.lib` so LabVIEW loads your Icon Editor source directly, it also removes `lv_icon.lvlibp`.
+- Enable/disable via the **Development Mode Toggle** workflow.
+
+**Testing / Distributable Builds**
+- Usually done in a **normal** LabVIEW environment (Dev Mode disabled).
+- Ensures that the `.vip` artifact or tests reflect a standard environment.
+
+
+
+### 2. Available GitHub Actions
+
+1. **Development Mode Toggle**
+ - `mode: enable` → calls `Set_Development_Mode.ps1`.
+ - `mode: disable` → calls `RevertDevelopmentMode.ps1`.
+ - Great for reconfiguring LabVIEW for local dev vs. distribution builds.
+
+2. **Build VI Package & Release**
+ - **Label-based** semantic versioning (`major`, `minor`, `patch`). Defaults to `patch` if no label.
+ - **Counts existing tags** (`v*.*.*-build*`) to increment the global build number.
+ - **Fork-friendly** GPG: disabled for forks to avoid passphrase prompts.
+ - Publishes `.vip` as an artifact and optionally creates a GitHub Release if not a pull request.
+ - **Branding the Package**:
+ - You can **pass** metadata parameters like `-CompanyName` and `-AuthorName` into the build script. These map to fields in the **VI Package** (e.g., “Company Name,” “Author Name (Person or Company)”).
+ - This means each package can show the **organization** and **repository** that produced it, providing a **unique ID** if you have multiple forks or parallel versions.
+
+3. **Run Unit Tests**
+ - Executes test scripts to validate your Icon Editor code in a stable environment.
+
+
+
+### 3. Setting Up a Self-Hosted Runner
+
+**Steps**:
+
+1. **Install LabVIEW 2021 SP1 (32-bit and 64-bit)**
+ - Confirm both are present on your Windows machine.
+ - Apply `Tooling/deployment/runner_dependencies.vipc` to each if needed.
+
+2. **Install PowerShell 7+ and Git**
+ - Reboot if newly installed so environment variables are recognized.
+
+3. **Add a Self-Hosted Runner**
+ - **Settings → Actions → Runners** → **New self-hosted runner**
+ - Follow GitHub’s CLI instructions.
+
+4. **Labels** (optional)
+ - If the workflow references `runs-on: [self-hosted, iconeditor]`, label your runner accordingly or update the YAML’s `runs-on` lines.
+
+
+
+### 4. Running the Actions Locally
+
+With your runner online:
+
+1. **Enable Dev Mode** (if needed)
+ - **Actions → Development Mode Toggle**, set `mode: enable`.
+
+2. **Run Unit Tests**
+ - Confirm everything passes in logs. Some tests might rely on dev mode; see the logs for details.
+
+3. **Build VI Package & Release**
+ - Produces `.vip`, bumps the version, and can create a Git tag + GitHub Release (if not a PR).
+ - **Pass** your **org/repo** info (e.g. `-CompanyName "AcmeCorp"` / `-AuthorName "AcmeCorp/IconEditor"`) to embed in the final package.
+ - Artifacts appear in the run summary under **Artifacts**.
+
+4. **Disable Dev Mode** (if used)
+ - `mode: disable` reverts your LabVIEW environment.
+
+5. **Review the `.vip`**
+ - Download from **Artifacts** or check your Release page if a release was created.
+
+
+
+### 5. Example Developer Workflow
+
+1. **Enable Development Mode**: if you plan to actively modify the Icon Editor code inside LabVIEW.
+2. **Code & Test**: Make changes, run **Run Unit Tests** to confirm stability.
+3. **Open a Pull Request**:
+ - Assign a version bump label if you want `major`, `minor`, or `patch`.
+ - The workflow checks this label upon merging.
+4. **Merge**:
+ - **Build VI Package & Release** triggers, incrementing version and uploading `.vip`.
+ - **Metadata** (such as company/repo) is already integrated into the final `.vip`, so each build is easily identified.
+5. **Disable Dev Mode**: Return to a normal LabVIEW environment.
+6. **Install & Verify**: Download the `.vip` artifact for final validations.
+
+---
+
+## 4. Next Steps
+
+- **Check the Main Repo’s [README.md](../README.md)**: for environment disclaimers, additional tips, or project-specific instructions.
+- **Extend the Workflows**: You can add custom steps for linting, coverage, or multi-version LabVIEW tests.
+- **Submit Pull Requests**: If you refine scripts or fix issues, open a PR with logs showing your updated workflow runs.
+- **Troubleshoot**: If manual environment edits are needed, consult `ManualSetup.md` or the original documentation for advanced configuration steps.
+
+**Happy Building!** By integrating these workflows, you’ll maintain a **robust, automated CI/CD** pipeline for the LabVIEW Icon Editor—complete with **semantic versioning**, **build artifact uploads**, **metadata branding** (company/repo), and **GPG-signing** or **GPG-free** mode for forks.
\ No newline at end of file
diff --git a/docs/ci/actions/troubleshooting-experiments.md b/docs/ci/actions/troubleshooting-experiments.md
new file mode 100644
index 00000000..7b418050
--- /dev/null
+++ b/docs/ci/actions/troubleshooting-experiments.md
@@ -0,0 +1,280 @@
+# Troubleshooting experimental branches
+
+Welcome to the **Troubleshooting Guide** for experimental branches. This document aims to help you quickly identify common pitfalls and resolve issues that may arise when working with **long-lived experiment branches** in our GitFlow-like model. Below, you will find **20 typical scenarios** grouped into subsections—each with a **symptom**, a **cause**, and a **solution** (including commands where relevant).
+
+---
+
+## Subsection A: Setup & Approval
+
+### 1. Experiment Branch Not Created After Steering Committee Approval
+
+**Symptom**
+You’ve received approval from the Steering Committee, but you don’t see `experiment/` in the repository.
+
+**Cause**
+NI maintainers or an admin is responsible for actually creating the experiment branch. They might not have completed this step yet.
+
+**Solution (One Paragraph)**
+Reach out to the maintainer or Open Source Program Manager and confirm they have time to create `experiment/` from `develop`. You can provide them with your shortName if needed (e.g., “experiment/async-rework”). Once the branch is created, refresh your repository page or pull the latest remote branches locally. If it still doesn’t show, verify you have the correct permissions and that the branch was indeed pushed to origin.
+
+---
+
+### 2. “approve-experiment” Dispatch Missing from Actions
+
+**Symptom**
+You’re attempting to enable official artifact distribution for your experiment, but you cannot find the “approve-experiment” workflow under GitHub Actions.
+
+**Cause**
+Either the repository’s CI config does not include the “approve-experiment” workflow, or it was inadvertently commented out or renamed.
+
+**Solution (One Paragraph)**
+Check the `.github/workflows` folder in the main repo for a file that defines the “approve-experiment” job. If missing, ask a maintainer to add it or confirm the correct name. Sometimes the workflow might be called “Approve Experiment.” If the workflow does exist, verify that the file is not disabled in repository settings and that you have admin or maintainer privileges to see manual workflows. Once confirmed, you should see a **“Run workflow”** button in the Actions tab where you select your experiment branch.
+
+---
+
+### 3. Code Scanning Warnings Blocking Approval
+
+**Symptom**
+You want NI to approve artifact distribution, but they refuse because the scanning tool warns of potential issues in your experiment branch.
+
+**Cause**
+Your commits contain patterns that the scanning tool interprets as security or quality risks. Maintainers want them resolved before enabling distribution.
+
+**Solution (One Paragraph)**
+Review the scanning report in the Action logs. Fix each flagged issue or comment on why it’s a false positive. Then push new commits to your experiment branch. Once scans are clean or acceptable, maintainers should recheck the logs. With the warnings addressed, they can safely run the “approve-experiment” dispatch and allow artifact publication.
+
+---
+
+### 4. “NoCI” Label Remains Even After Manual Approval
+
+**Symptom**
+You see a “NoCI” label on your experiment branch in GitHub, even though an admin triggered the “approve-experiment” event.
+
+**Cause**
+The specialized GitFlow Action might not automatically remove the “NoCI” label, or the admin’s manual event did not successfully update the branch’s labels.
+
+**Solution (One Paragraph)**
+Check the workflow logs to ensure the “approve-experiment” step completed. If the label persists, an admin can manually remove “NoCI” from the branch or PR. Confirm that the environment variable or config toggling “ApprovedCI” is set to `true`. If the action depends on label removal to start builds, you can remove it in the GitHub UI under “Labels.”
+
+---
+
+### 5. Unsure How to Name the Experiment Branch
+
+**Symptom**
+You want to start an experiment but are uncertain which name to use or how long it can be.
+
+**Cause**
+There’s no strict naming enforcement aside from the recommended `experiment/` pattern, leading to confusion.
+
+**Solution (One Paragraph)**
+Follow the recommended naming: `experiment/` prefix plus a concise identifier (e.g., `experiment/ui-overhaul`). Avoid spaces or punctuation that might break scripts. If your feature involves something bigger, be sure to keep it short but descriptive—like `experiment/performance-refactor`. Keeping a consistent naming scheme helps everyone quickly identify the branch as an experiment.
+
+---
+
+## Subsection B: Merging & Sub-Branches
+
+### 6. Merge Conflicts When Pulling from `develop` into Experiment
+
+**Symptom**
+Frequent conflicts occur whenever you merge updated `develop` changes into your experiment branch.
+
+**Cause**
+Your experiment has diverged significantly from `develop`; the code scanning or action logs might also indicate repeated merges.
+
+**Solution (One Paragraph)**
+Merge or rebase from `develop` **regularly**, at least once every few weeks, to reduce large conflict sets. If the conflicts are already massive, break them down by merging `develop` in smaller increments or isolate file sets. Also ensure your local environment is fully updated before pulling. Once resolved locally, push the updated experiment branch so your collaboration stays in sync.
+
+---
+
+### 7. alpha → beta → rc Sub-Branches Not Merging Properly
+
+**Symptom**
+You’ve created `experiment//alpha`, then `beta`, but merges from alpha to beta produce unexpected code changes or partial merges missing.
+
+**Cause**
+Team members are working in multiple sub-branches without a clear merge order, or you’re skipping essential merges between them.
+
+**Solution (One Paragraph)**
+Establish a clear pipeline: alpha → beta → rc. Finish changes in alpha, merge them fully into beta, then into rc. Communicate the merge order to all collaborators so no one merges rc changes backward into alpha. Use a consistent naming approach and confirm each branch merges cleanly before moving to the next. If needed, use PRs for each stage so the specialized Action logs the merges systematically.
+
+---
+
+### 8. Accidental Direct Commits to `rc` Instead of `beta`
+
+**Symptom**
+A collaborator commits code directly onto your `experiment//rc` branch, bypassing the alpha or beta stage.
+
+**Cause**
+Lack of clarity on the sub-branch flow; the collaborator had push access and accidentally targeted the rc branch.
+
+**Solution (One Paragraph)**
+Explain the sub-branch staging approach: alpha is for early changes, beta is for stabilizing, and rc is for near-final. Revert or cherry-pick those commits onto the correct sub-branch if necessary. Update branch protection rules to disallow direct commits to `rc` or require a PR with lead approval.
+
+---
+
+### 9. Attempting Partial Merge from Sub-Branch into `develop`
+
+**Symptom**
+A user tries to bypass the main experiment trunk and do a partial merge from `beta` or `rc` directly into `develop`.
+
+**Cause**
+They only want certain improvements from the experiment to land early in `develop`, or they misunderstand the final big-bang approach.
+
+**Solution (One Paragraph)**
+It’s acceptable to do partial merges if the code is stable, but coordinate with the experiment lead. Typically, you create a new branch from `beta` or `rc` with the relevant commits and open a PR to `develop`. This ensures the experiment’s main line remains consistent while letting you deliver urgent features or fixes earlier.
+
+---
+
+### 10. Steering Committee Forgets to Approve Final Merge
+
+**Symptom**
+The final PR from `experiment/` to `develop` is open, but no one merges it because the Steering Committee hasn’t labeled it “major,” “minor,” or “patch.”
+
+**Cause**
+They might have overlooked the PR or expected more clarifications.
+
+**Solution (One Paragraph)**
+Politely ping the Steering Committee members or reference them in a comment: “@SteeringCommittee, can we finalize the labeling for this PR?” Remind them the specialized action needs that label to do the mainline version bump. If it’s time-sensitive, also note that the BDFL override is possible if they need an immediate merge.
+
+---
+
+## Subsection C: Collaboration & Scanning
+
+### 11. Conflicting Scans from Two Contributors
+
+**Symptom**
+Two collaborators push changes that trigger code scanning with contradictory or overlapping warnings. The logs become messy or contradictory.
+
+**Cause**
+Multiple commits in short succession can cause the scanning steps to produce separate sets of warnings.
+
+**Solution (One Paragraph)**
+Coordinate commits so that one contributor merges or rebases after the other’s scanning results are addressed. If both scanning logs are relevant, unify them by merging whichever commit came first. Re-run the scanning steps or push a new commit that addresses all flagged items. Encourage communication to avoid overlapping partial fixes.
+
+---
+
+### 12. Mysterious “No Artifact Generated” for a PR
+
+**Symptom**
+When a collaborator opens a pull request into `experiment/`, the build step completes but no final artifact is attached.
+
+**Cause**
+If the push is from a **fork** or a branch that’s not recognized by the specialized action’s conditions, the packaging might be set to skip. Alternatively, the scanning tool might fail before packaging.
+
+**Solution (One Paragraph)**
+Check the logs carefully. If scanning fails, packaging is typically aborted. Also confirm that your GitHub Action includes `pull_request` triggers for experiment branches. If it’s from a fork, the collaborator might need a PR from the fork’s branch into `experiment/`, ensuring they have “Allow actions from external PRs” or a manual approval from a maintainer.
+
+---
+
+### 13. Code Scanning Always Times Out
+
+**Symptom**
+Every commit to your experiment takes forever or times out in the scanning stage.
+
+**Cause**
+The code scanning tool might be analyzing a large codebase or unoptimized scanning rules. Possibly a slow or busy runner environment.
+
+**Solution (One Paragraph)**
+Break your commits or code changes into smaller chunks. Revisit the scanning rules to exclude non-critical areas. If your environment is overburdened, ask a maintainer about scheduling scans or using more powerful runners. If partial scanning is acceptable, temporarily disable scanning on minor files until final integration.
+
+---
+
+### 14. Approve-Experiment Workflow Succeeds but “NoCI” Stays in Logs
+
+**Symptom**
+The final step in the “approve-experiment” workflow claims success, but the logs still mention “NoCI” being active on subsequent commits.
+
+**Cause**
+It could be a caching or environment variable issue. Possibly the specialized Action never wrote the updated “ApprovedCI” state to the correct config.
+
+**Solution (One Paragraph)**
+Open the Approve-Experiment workflow logs. Look for lines saying “Successfully toggled from NoCI to ApprovedCI.” If absent, re-run the event. If the config file or environment variable is in a separate branch, ensure it merges into `experiment/`. Once verified, the next push should show logs referencing “ApprovedCI.”
+
+---
+
+### 15. Another Repo’s Changes Not Flowing Down to the Experiment
+
+**Symptom**
+The specialized action or scanning updates made on `main` repo aren’t reflected in your experiment-based repo or a collaborator’s fork.
+
+**Cause**
+The changes in the action or scanning config are not automatically pulled into every existing branch or fork. They require a manual pull or rebase from upstream.
+
+**Solution (One Paragraph)**
+Explain to collaborators that, if they’re on an older version of the specialized Action or scanning config, they must merge from the upstream `main` or `develop` to incorporate those updates. For forks, they can open a PR from upstream. Once merged, the new pipeline changes will appear in their experiment branch or fork.
+
+---
+
+## Subsection D: Final Integration & Advanced Issues
+
+### 16. One-Year Experiment Overwhelms the Final Merge
+
+**Symptom**
+An experiment that lasted ~1 year has massive changes, making the final PR extremely large and difficult to review.
+
+**Cause**
+No incremental merges were done, so develop and the experiment diverged significantly.
+
+**Solution (One Paragraph)**
+Encourage partial merges or chunk-based merges well before the 1-year mark. If you’re already at a big-bang PR, break it into smaller merges if feasible (like a “phase1” sub-branch). Conduct thorough reviews in stages or rely on thorough testing. Also check the scanning logs carefully for each phase to ensure no hidden regressions.
+
+---
+
+### 17. Lost “rc” Branch Before Merging to develop
+
+**Symptom**
+The `experiment//rc` sub-branch was accidentally deleted or overwritten, losing final release candidate changes.
+
+**Cause**
+A mistaken force-push or deletion by a collaborator who misunderstood the branch’s purpose.
+
+**Solution (One Paragraph)**
+Check your Git history or any open pull requests that might reference the `rc` commits. You can restore the branch from the relevant commit hash if found in logs or merges. Communicate the importance of not force-pushing without lead approval. If you cannot restore it, revert to `beta` or older commits and rebuild the rc changes from memory or PR diffs.
+
+---
+
+### 18. Steering Committee Sets Wrong Label (Major/Minor/Patch)
+
+**Symptom**
+They labeled the final PR “minor,” but you suspect it’s actually a “major” release. The specialized Action merges it as “minor.”
+
+**Cause**
+Possibly a committee oversight or misunderstanding of the changes’ scope.
+
+**Solution (One Paragraph)**
+Discuss it in the PR or mention the BDFL for a final call. If the merge already happened, the version is set. You can do an immediate follow-up PR to correct the version label or do a new “major” label if it’s truly that big. Document the reason for re-labeling so future references are consistent.
+
+---
+
+### 19. Conflict Between Two Simultaneous Experiments
+
+**Symptom**
+Two experiment branches overlap in scope, and maintainers are unsure how merges from each experiment eventually unify in `develop`.
+
+**Cause**
+Large or overlapping changes in distinct branches create uncertain interactions. No cross-communication between leads.
+
+**Solution (One Paragraph)**
+Encourage the leads to share progress and possibly do a “sync branch” that merges both experiments. If they remain separate, each experiment merges into `develop` in sequence, with the second lead reconciling conflicts. Steering Committee can help schedule which merges first to minimize chaos. Keep scanning each experiment individually until both finalize.
+
+---
+
+### 20. Approve-Experiment Trigger Overused
+
+**Symptom**
+An admin is re-running “approve-experiment” every few commits for no apparent reason, causing confusion about the actual “NoCI” vs. “ApprovedCI” state.
+
+**Cause**
+A misunderstanding that “approve-experiment” must be repeated after each scanning pass or that the experiment lead wants incremental approvals.
+
+**Solution (One Paragraph)**
+Clarify that typically one approval suffices to switch from “NoCI” → “ApprovedCI,” letting you build artifacts indefinitely. The only time you might re-run is if the scope drastically changed or if you intentionally toggled it off due to scanning issues. Maintain consistent logs to avoid accidental repeated toggling. Document or have a policy limiting how many times “approve-experiment” is run for a single branch.
+
+---
+
+## See Also
+- [EXPERIMENTS.md](../EXPERIMENTS.md) – How to propose & manage experimental branches.
+- [MAINTAINERS_GUIDE.md](docs/ci/actions/maintainers-guide.md) – Admin tasks & final merges.
+- [GOVERNANCE.md](./GOVERNANCE.md) – Steering Committee roles, BDFL structure.
+
+---
diff --git a/docs/ci/experiments.md b/docs/ci/experiments.md
new file mode 100644
index 00000000..eac424ea
--- /dev/null
+++ b/docs/ci/experiments.md
@@ -0,0 +1,161 @@
+# Experimental branches
+
+> **Note**: This document provides a **step-by-step guide** for our **GitFlow-like experimental branches** for our **long-lived, multi-collaborator** features (e.g., 6–8 weeks or up to 1–1.5 years) that eventually merge back into the main product code.
+
+## Table of Contents
+1. [Overview](#overview)
+2. [Key Concepts](#key-concepts)
+3. [Why NI Wants Experimental Branches in This Repo](#why-ni-wants-experimental-branches-in-this-repo)
+4. [Detailed & Comprehensive Narrative](#detailed--comprehensive-narrative)
+5. [Step-by-Step Workflow](#step-by-step-workflow)
+ - [Step 1: Propose an Experiment](#step-1-propose-an-experiment)
+ - [Step 2: Create `experiment/`](#step-2-create-experimentshortname)
+ - [Step 3: Automated Scans & Manual Approval](#step-3-automated-scans--manual-approval)
+ - [Step 4: (Optional) Alpha/Beta/RC Sub-Branches](#step-4-optional-alphabetarc-sub-branches)
+ - [Step 5: Merge Frequency from `develop`](#step-5-merge-frequency-from-develop)
+ - [Step 6: Final Merge to `develop`](#step-6-final-merge-to-develop)
+ - [Step 7: Partial or Abandoned Experiments](#step-7-partial-or-abandoned-experiments)
+6. [Conclusion & Best Practices](#conclusion--best-practices)
+7. [See Also](#see-also)
+
+---
+
+# Overview
+Long-lived **experimental branches** (`experiment/`) allow you to develop complex features in an isolated environment.
+
+- **Multi-collaborator**: Multiple contributors can push or PR into the experiment.
+- **Length**: Typically 6–8 weeks or up to 1–1.5 years.
+- **Goal**: Eventually merge these experiments into `develop` if deemed successful.
+
+**Why This Model?**
+- Reduce disruption to day-to-day merges in `develop`.
+- Provide a “pseudo-develop” for features needing alpha/beta/rc staging.
+- Enforce code scanning and manual approval for distributing `.vip` artifacts (or equivalent), ensuring security.
+
+---
+
+## Key Concepts
+
+1. **experiment/**
+ - The main branch for the experiment, created by an NI maintainer post Steering Committee approval.
+2. **Automatic Scanning**
+ - Docker VI Analyzer & CodeQL run on every commit or PR, catching suspicious code before distribution.
+3. **Manual Approval**
+ - By default, `.vip` packaging is disabled. An NI admin must run an “approve-experiment” workflow to enable artifact distribution for the experiment.
+4. **Alpha/Beta/RC**
+ - Optional sub-branches under `experiment/` if your team wants mini-stages of development.
+5. **Big-Bang Merge**
+ - Ultimately, `experiment/` merges into `develop` with a final Steering Committee review and version label (major/minor/patch).
+
+---
+
+## Why NI Wants Experimental Branches in This Repo
+
+NI’s primary goal is to make **collaboration** on significant, **long-running** features both **safe and productive**:
+
+1. **Centralized Testing & CI**
+ - By hosting these experiment branches directly in NI’s main repository, contributors can leverage **official** CI pipelines, scanning tools, and `.vip` build workflows.
+ - This ensures potential large-scale or risky features still benefit from **consistent** environment checks and automation.
+
+2. **Early Feedback & Transparency**
+ - When experiments happen in **NI’s repo**, stakeholders—including external collaborators and NI R&D—can observe progress in real-time, **test** artifacts promptly, and give feedback early.
+ - This **transparency** supports a faster iteration cycle and a smoother eventual merge into the shipping version of the software.
+
+3. **Coordinated Merges & Oversight**
+ - Hosting experimental branches in the main repo facilitates **oversight** by the Steering Committee, enabling them to guide or course-correct large features.
+ - It also simplifies final merges: everything is already in the same place, so merging an experiment into `develop` doesn’t involve complicated cross-repo synchronization.
+
+4. **Security & Quality**
+ - Experimental branches remain subject to **automatic code scanning** (Docker VI Analyzer + CodeQL).
+ - Manual gating of `.vip` distribution ensures NI’s brand and user base are not exposed to unreviewed or potentially insecure code.
+
+5. **Enhanced Innovation**
+ - NI wants to encourage **bigger** ideas from the community. By offering direct experiment branches under its official repo, contributors see that NI invests in supporting **innovative** or **ambitious** projects beyond the standard short-lived feature approach.
+
+---
+
+## Detailed & Comprehensive Narrative
+
+1. **Proposal & Scope**
+ - A contributor—internal or external—proposes a **significant** feature via a GitHub Issue, detailing high-level goals and a timeline ranging 6–8 weeks to potentially 1–1.5 years.
+ - The Steering Committee weighs strategic impact, checking if the feature aligns with the roadmap and is worth integrating into `develop` eventually.
+
+2. **Steering Committee & Rationale**
+ - If deemed valuable, NI (in coordination with the Steering Committee) will create `experiment/` from `develop`.
+ - All code scanning (Docker VI Analyzer, CodeQL) applies automatically, but artifacts remain gated to protect the broader user base from incomplete or unverified changes.
+
+3. **Experiment Branch as a Pseudo-Develop**
+ - The experiment branch acts like a **“mini development”** line. Multiple collaborators can open sub-branches, do alpha/beta testing, or run partial merges—**all within** the experiment.
+ - Merges or updates to `develop` can happen periodically to reduce future conflicts.
+
+4. **Security & Manual Approval**
+ - NI uses a manual “approve-experiment” workflow to **activate** `.vip` distribution for that experiment. This ensures potential large-scale distributions only happen once the scans show no critical issues and the maintainers are confident in its safety.
+
+5. **Alpha/Beta/RC Sub-Branches**
+ - If the feature is especially big or has distinct phases, sub-branches (`alpha`, `beta`, `rc`) can help test certain milestones or gather feedback from a smaller or larger group.
+
+6. **Frequent Synchronization**
+ - Since the experiment might run **months**, merging `develop` changes into it periodically prevents a massive final conflict resolution stage.
+
+7. **Integration Path**
+ - Eventually, the experiment lead or Steering Committee opens a PR from `experiment/` to `develop`. The Steering Committee:
+ - Chooses a final version bump label (major/minor/patch).
+ - Merges if everything passes final checks.
+ - Unsuccessful or partial features can be archived or broken into smaller merges.
+
+8. **Abandonment or Partial Merges**
+ - Some experiments may fail or lose relevance. NI can archive or delete the branch if so. If only half the experiment is viable, cherry-picking or partial merges are possible.
+
+---
+
+## Step-by-Step Workflow
+
+### Step 1: Propose an Experiment
+- **GitHub Issue**: Outline feature scope, timeline, potential collaborators, rationale for why it needs an experimental approach.
+- **Steering Committee**: They either approve or reject, considering if the feature should live in `experiment/` on NI’s repo.
+
+### Step 2: Create `experiment/`
+- **NI Maintainer**: Creates `experiment/` from `develop`.
+- **NoCI**: By default, distributing `.vip` or similar artifacts is disabled until manual approval.
+
+### Step 3: Automated Scans & Manual Approval
+- **Docker VI Analyzer + CodeQL**: Automatically run on every commit/PR.
+- **Manual “approve-experiment”**: An NI admin triggers a workflow to enable `.vip` or artifact builds for the experiment once scans are deemed acceptable.
+
+### Step 4: (Optional) Alpha/Beta/RC Sub-Branches
+- If staged development is beneficial, the experiment lead can create sub-branches:
+ - `experiment//alpha`
+ - `experiment//beta`
+ - `experiment//rc`
+
+### Step 5: Merge Frequency from `develop`
+- **Best Practice**: Merge `develop` into `experiment/` every couple of weeks or as needed, preventing large-scale conflicts at the end.
+
+### Step 6: Final Merge to `develop`
+- **Open a PR**: From `experiment/` or `rc` sub-branch to `develop`.
+- **Steering Committee**: Labels “major/minor/patch.”
+- **Merge**: The entire experiment is integrated into `develop`. Branch is removed or archived.
+
+### Step 7: Partial or Abandoned Experiments
+- **Partial Merge**: If only some commits are viable, cherry-pick or do a specialized branch to integrate them.
+- **Abandoned**: Archive or delete the experiment branch if it’s no longer relevant.
+
+---
+
+## Conclusion & Best Practices
+
+- **Motivation**: NI hosts experiments in this repo to offer official CI, early feedback, and centralized scanning for large or innovative features.
+- **Communication**: Keep the Steering Committee and collaborators informed through GitHub issues/PRs.
+- **Security & Approval**: Automated code scans plus manual gating for artifact distribution safeguard the community from half-baked or risky releases.
+- **Sub-Branches**: Use alpha/beta/rc to manage internal staging if desired.
+- **Frequent Sync**: Merging from `develop` regularly saves time on final conflict resolution.
+- **Endgame**: Merge the experiment into `develop` in one final PR, or partially if only a subset of commits succeed, or abandon/archiving if it fails.
+
+---
+
+## See Also
+- [MAINTAINERS_GUIDE.md](./actions/maintainers-guide.md) — For how admins run the “approve-experiment” workflow, how final merges are labeled.
+- [TROUBLESHOOTING_EXPERIMENTS.md](./actions/troubleshooting-experiments.md) — Ten common pitfalls (e.g., missing `.vip` files, partial merges).
+- [GOVERNANCE.md](./GOVERNANCE.md) — Steering Committee roles, BDFL membership, and how experiments get approved.
+
+---
diff --git a/docs/ci/troubleshooting-faq.md b/docs/ci/troubleshooting-faq.md
new file mode 100644
index 00000000..cf6c6dea
--- /dev/null
+++ b/docs/ci/troubleshooting-faq.md
@@ -0,0 +1,369 @@
+# Troubleshooting & FAQ
+
+This document provides a collection of common **troubleshooting** scenarios (with solutions) and a **FAQ** (Frequently Asked Questions) for the LabVIEW Icon Editor GitHub Actions workflows. Refer back to the main CI guide if you need overall setup instructions or deeper references.
+
+---
+
+## Table of Contents
+
+1. [Troubleshooting](#troubleshooting)
+ 1. [No. 1: LabVIEW Not Found on Runner](#no-1-labview-not-found-on-runner)
+ 2. [No. 2: GPG Key Missing or Invalid](#no-2-gpg-key-missing-or-invalid)
+ 3. [No. 3: No `.vip` Artifact Found](#no-3-no-vip-artifact-found)
+ 4. [No. 4: Version Label Not Recognized](#no-4-version-label-not-recognized)
+ 5. [No. 5: Build Number Not Updating](#no-5-build-number-not-updating)
+ 6. [No. 6: Dev Mode Still Enabled After Build](#no-6-dev-mode-still-enabled-after-build)
+ 7. [No. 7: Release Not Created or Drafted](#no-7-release-not-created-or-drafted)
+ 8. [No. 8: Branch Protection Blocks Merge](#no-8-branch-protection-blocks-merge)
+ 9. [No. 9: Incorrect Pre-Release Suffix (Alpha/Beta/RC)](#no-9-incorrect-pre-release-suffix-alphabetarc)
+ 10. [No. 10: Hotfix Not Tagged as Expected](#no-10-hotfix-not-tagged-as-expected)
+ 11. [No. 11: Double-Dash Parameters Not Recognized](#no-11-double-dash-parameters-not-recognized)
+ 12. [No. 12: Company/Author Fields Not Populating](#no-12-companyauthor-fields-not-populating)
+ 13. [No. 13: JSON Fields Overwritten Incorrectly](#no-13-json-fields-overwritten-incorrectly)
+ 14. [No. 14: Repository Forks Not Displaying Correct Metadata](#no-14-repository-forks-not-displaying-correct-metadata)
+
+
+2. [FAQ](#faq)
+ 1. [Q1: Can I Override the Build Number?](#q1-can-i-override-the-build-number)
+ 2. [Q2: How Do I Skip Creating a Release?](#q2-how-do-i-skip-creating-a-release)
+ 3. [Q3: Can I Have More Than Alpha/Beta/RC Channels?](#q3-can-i-have-more-than-alphabeta-rc-channels)
+ 4. [Q4: Do I Need a GPG Key to Build on a Fork?](#q4-do-i-need-a-gpg-key-to-build-on-a-fork)
+ 5. [Q5: How Can I Attach Multiple `.vip` Files to a Release?](#q5-how-can-i-attach-multiple-vip-files-to-a-release)
+ 6. [Q6: Do I Need To Merge Hotfixes Into `develop`?](#q6-do-i-need-to-merge-hotfixes-into-develop)
+ 7. [Q7: What If I Don’t Want a Draft Release?](#q7-what-if-i-dont-want-a-draft-release)
+ 8. [Q8: Can I Use This Workflow Without Gitflow?](#q8-can-i-use-this-workflow-without-gitflow)
+ 9. [Q9: Why Is My Dev Mode Toggle Not Working Locally?](#q9-why-is-my-dev-mode-toggle-not-working-locally)
+ 10. [Q10: Can I Use a Different LabVIEW Version (e.g., 2023)?](#q10-can-i-use-a-different-labview-version-eg-2023)
+ 11. [Q11: How Do I Pass Repository Name and Organization?](#q11-how-do-i-pass-repository-name-and-organization)
+ 12. [Q12: Can I Omit the Company/Author Fields in My JSON?](#q12-can-i-omit-the-companyauthor-fields-in-my-json)
+ 13. [Q13: Why Must I Use Single-Dash Instead of Double-Dash?](#q13-why-must-i-use-single-dash-instead-of-double-dash)
+ 14. [Q14: Can I Add More Fields to the VIPB Display Information?](#q14-can-i-add-more-fields-to-the-vipb-display-information)
+
+
+---
+
+## Troubleshooting
+
+Below are 14 possible issues you might encounter, along with suggested steps to resolve them.
+
+### No. 1: LabVIEW Not Found on Runner
+
+**Symptoms**:
+- The workflow fails with an error like “LabVIEW executable not found” or “Command not recognized.”
+
+**Possible Causes**:
+- LabVIEW isn’t installed on the self-hosted runner.
+- The environment variable or path to LabVIEW isn’t set correctly.
+
+**Solution**:
+1. Ensure you’ve actually installed LabVIEW on the machine (e.g., LabVIEW 2021 SP1).
+2. Double-check your PATH or environment variables.
+3. See `runner-setup-guide.md` for details on configuring the runner to locate LabVIEW.
+
+---
+
+### No. 2: GPG Key Missing or Invalid
+
+**Symptoms**:
+- The workflow tries to sign a tag or release, then fails with “gpg: signing failed: No secret key” or a passphrase prompt.
+
+**Possible Causes**:
+- You’re on the main repository but haven’t set up the required GPG key.
+- On a fork, GPG is disabled, but the script is still attempting to sign.
+
+**Solution**:
+1. If you’re running on a fork, set `DISABLE_GPG_ON_FORKS=true`.
+2. If you’re on the main repo, ensure the GPG key is installed, and the passphrase (if any) is available to the workflow.
+3. Confirm your GitHub Actions secrets are correctly set for GPG usage (e.g., `GPG_PRIVATE_KEY`, `PASSPHRASE`).
+
+---
+
+### No. 3: No `.vip` Artifact Found
+
+**Symptoms**:
+- The build succeeds, but the “Upload artifact” step fails with “File not found” or empty artifact.
+
+**Possible Causes**:
+- The `Build.ps1` script didn’t actually produce a `.vip` file in the expected folder.
+- The workflow’s “paths” setting doesn’t match the output directory.
+
+**Solution**:
+1. Check your “Build VI Package” job logs to confirm the `.vip` file was created.
+2. If it’s created in `builds/VI Package/`, ensure the upload step references that folder.
+3. Verify the version of VI Package Manager or the build scripts aren’t failing silently.
+
+---
+
+### No. 4: Version Label Not Recognized
+
+**Symptoms**:
+- You labeled your Pull Request “minor” or “patch,” but the version doesn’t increment that segment.
+
+**Possible Causes**:
+- The workflow only checks for certain labels (`major`, `minor`, `patch`). Typos or different capitalization might be ignored.
+- You’re pushing directly to a branch instead of creating a PR (so no label is read).
+
+**Solution**:
+1. Make sure the label is exactly `major`, `minor`, or `patch` in lowercase (unless your workflow script also checks for capitalized labels).
+2. Confirm you’re actually using a Pull Request event (not a direct push).
+3. Check logs for “Determining Bump Type” in the Build VI Package workflow.
+
+---
+
+### No. 5: Build Number Not Updating
+
+**Symptoms**:
+- Every build produces the same “-buildN” suffix, or the commit count doesn’t match reality.
+
+**Possible Causes**:
+- `fetch-depth` in `actions/checkout` might be set to `1`, causing an incomplete commit history.
+- The script uses `git rev-list --count HEAD`, but partial history returns a smaller number.
+
+**Solution**:
+1. In your workflow’s checkout step, set `fetch-depth: 0` (full history).
+2. Verify you haven’t overridden the default `git rev-list --count` command.
+3. Check that your repository is fully cloned on the runner.
+
+---
+
+### No. 6: Dev Mode Still Enabled After Build
+
+**Symptoms**:
+- You run a build, but the environment remains in “development mode,” causing odd behavior when installing `.vip`.
+
+**Possible Causes**:
+- You forgot to run the “disable” step of the Development Mode Toggle.
+- Another step re-applied the `Set_Development_Mode.ps1` script.
+
+**Solution**:
+1. Manually run the “Development Mode Toggle” workflow with `mode=disable`.
+2. Confirm your pipeline sequence: typically, dev mode is enabled for debugging only, then disabled prior to final builds.
+
+---
+
+### No. 7: Release Not Created or Drafted
+
+**Symptoms**:
+- The workflow completes, but you see no new release in GitHub’s “Releases” section.
+
+**Possible Causes**:
+- `DRAFT_RELEASE` is set to `true` (so it’s in draft state), or the “Create Release” step was skipped.
+- The build was triggered by a Pull Request, and your workflow logic only creates releases on “push” or merges to main.
+
+**Solution**:
+1. Check your workflow triggers: releases are often created only on direct pushes to specific branches.
+2. If `DRAFT_RELEASE == true`, look in “Releases → Drafts” to publish it manually.
+3. Confirm you have “Read and write” permissions for Actions in your repo settings.
+
+---
+
+### No. 8: Branch Protection Blocks Merge
+
+**Symptoms**:
+- You can’t merge into `main` or `release-alpha/*`; GitHub says “Branch is protected.”
+
+**Possible Causes**:
+- Strict branch protection rules require approvals or passing checks before merging.
+- You’re lacking the required PR reviews or status checks.
+
+**Solution**:
+1. Have the required reviewers approve your Pull Request.
+2. Ensure the “Build VI Package” and “Run Unit Tests” checks pass.
+3. Update your `CONTRIBUTING.md` to specify the merging rules so contributors know what’s needed.
+
+---
+
+### No. 9: Incorrect Pre-Release Suffix (Alpha/Beta/RC)
+
+**Symptoms**:
+- You expected a `-beta.` suffix, but got `-alpha.` or no suffix at all.
+
+**Possible Causes**:
+- Your branch name doesn’t match the required pattern: `release-beta/*`.
+- The script that checks for alpha/beta/rc might not be updated for your custom naming.
+
+**Solution**:
+1. Rename your branch to the correct pattern: `release-beta/2.0`, `release-rc/2.0`, etc.
+2. If you changed naming conventions, update your workflow logic to detect them (e.g., a RegEx match).
+
+---
+
+### No. 10: Hotfix Not Tagged as Expected
+
+**Symptoms**:
+- Your hotfix branch merges produce a release, but the tag isn’t correct (e.g., it’s missing or still in RC mode).
+
+**Possible Causes**:
+- The workflow might treat `hotfix/*` like another pre-release branch if not configured properly.
+- The branch name might not match exactly `hotfix/` (e.g., `hotfix-2.0` without a slash).
+
+**Solution**:
+1. Ensure your code checks for `hotfix/` prefix, not `hotfix-`.
+2. Confirm you’re merging into main or the correct base.
+3. Verify the build logs to see how the workflow computed the version and tag.
+
+---
+
+### No. 11: Double-Dash Parameters Not Recognized
+
+**Symptoms**:
+- You see an error like:
+ *“A positional parameter cannot be found that accepts argument '--lv-ver'”*
+
+**Possible Causes**:
+- PowerShell scripts typically declare parameters with single dashes (e.g. `-SupportedBitness 64`).
+- The script has no parameter named `lv-ver` or `arch`, so passing `--lv-ver` or `--arch` triggers a parsing error.
+
+**Solution**:
+1. Remove or replace `--lv-ver` and `--arch` with valid single-dash parameters your script actually declares, such as `-MinimumSupportedLVVersion 2021` and `-SupportedBitness 64`.
+2. If you really want `--lv-ver`, you must update the script’s `param()` block to accept that alias.
+
+---
+
+### No. 12: Company/Author Fields Not Populating
+
+**Symptoms**:
+- The final `.vip` file’s metadata for “Company Name” or “Author Name (Person or Company)” remains empty.
+
+**Possible Causes**:
+- You didn’t pass `-CompanyName` or `-AuthorName` to the `Build.ps1` script.
+- The JSON creation step is missing or incorrectly references the parameters.
+
+**Solution**:
+1. In your GitHub Actions or local call, ensure you specify both `-CompanyName "XYZ Corp"` and `-AuthorName "my-org/repo"`.
+2. Check that the script’s code block generating `$DisplayInformationJSON` includes these fields.
+3. Confirm no conflicting code overwrote your JSON after you set it.
+
+---
+
+### No. 13: JSON Fields Overwritten Incorrectly
+
+**Symptoms**:
+- You see “Add-Member … already exists” errors, or your `Package Version` keys get overwritten unexpectedly.
+
+**Possible Causes**:
+- The script is re-adding or re-initializing the same JSON fields multiple times without using `-Force`.
+- Another function in the pipeline modifies the same subobject.
+
+**Solution**:
+1. Update your script to **conditionally** add fields only if they’re missing, or directly assign the property if it already exists.
+2. If needed, specify `Add-Member -Force` (though recommended approach is to check existence first).
+3. Ensure you only do the “Package Version” injection once in your pipeline.
+
+---
+
+### No. 14: Repository Forks Not Displaying Correct Metadata
+
+**Symptoms**:
+- A user forks the repository, but the `.vip` file still shows the **original** repo or organization name.
+
+**Possible Causes**:
+- The fork’s GitHub Actions workflow wasn’t updated to pass the new org name.
+- The fork’s build scripts are still using default or stale values for `-CompanyName` / `-AuthorName`.
+
+**Solution**:
+1. In the new fork, update the workflow to pass `-CompanyName "${{ github.repository_owner }}"` and `-AuthorName "${{ github.repository }}"`.
+2. Check that the script logic references those parameters for the final JSON.
+3. Review environment variables in GitHub Actions for the fork to ensure they’re set correctly.
+
+---
+
+## FAQ
+
+Below are 14 frequently asked questions about the CI workflow and Gitflow process.
+
+### Q1: Can I Override the Build Number?
+
+**Answer**:
+By default, the workflow calculates the build number with `git rev-list --count HEAD`. This ensures sequential builds. If you want a custom offset or manual override, you’d need to modify the build script. However, that breaks the linear progression and isn’t recommended.
+
+---
+
+### Q2: How Do I Skip Creating a Release?
+
+**Answer**:
+You can set an environment variable like `CREATE_RELEASE=false` (if your workflow supports it) or remove the “Create Release” step for certain branches. Another option is to let it create a draft release and simply never publish it.
+
+---
+
+### Q3: Can I Have More Than Alpha/Beta/RC Channels?
+
+**Answer**:
+Yes, you can add logic for `release-gamma/*` or any naming scheme. Just update the portion of your workflow that checks branch names and appends the appropriate suffix.
+
+---
+
+### Q4: Do I Need a GPG Key to Build on a Fork?
+
+**Answer**:
+No. If `DISABLE_GPG_ON_FORKS=true`, the signing process is disabled on forks to prevent missing key issues. You can still produce builds without GPG signatures.
+
+---
+
+### Q5: How Can I Attach Multiple `.vip` Files to a Release?
+
+**Answer**:
+Modify the artifact collection or upload steps to match multiple `.vip` patterns (e.g., `*.vip`). Then, in the “Attach Artifacts” step, loop over all matches and upload each.
+
+---
+
+### Q6: Do I Need To Merge Hotfixes Into `develop`?
+
+**Answer**:
+Yes. In standard Gitflow, after merging a `hotfix/*` into `main`, you also merge it back into `develop` so that your fix is reflected in ongoing development. Otherwise, you risk reintroducing the bug in future releases.
+
+---
+
+### Q7: What If I Don’t Want a Draft Release?
+
+**Answer**:
+Simply set `DRAFT_RELEASE=false`. The release will be published immediately after the workflow completes. Alternatively, you can remove or tweak that setting in your `.yml` file.
+
+---
+
+### Q8: Can I Use This Workflow Without Gitflow?
+
+**Answer**:
+Technically yes, if you don’t rely on alpha/beta/rc branch naming. But the workflow is designed with Gitflow in mind, so some features (like pre-release suffix detection) might not apply if you only have `main`.
+
+---
+
+### Q9: Why Is My Dev Mode Toggle Not Working Locally?
+
+**Answer**:
+The Dev Mode Toggle scripts rely on a self-hosted runner context. If you’re trying to run them directly on your machine outside GitHub Actions, you might need to adapt the PowerShell scripts or replicate the environment variables. Check logs to see if your system path matches what the scripts expect.
+
+---
+
+### Q10: Can I Use a Different LabVIEW Version (e.g., 2023)?
+
+**Answer**:
+Yes, if your machine and project support it. You’ll need to install that version on your self-hosted runner, and potentially update environment variables or references in the build scripts (e.g., specifying the correct LabVIEW EXE path). Just ensure everything in the project is compatible.
+
+---
+
+### Q11: How Do I Pass Repository Name and Organization?
+
+**Answer**:
+Inside **GitHub Actions**, you can reference environment variables such as `${{ github.repository_owner }}` and `${{ github.repository }}`. Pass them to your script (for example, `-CompanyName "$env:REPO_OWNER"` and `-AuthorName "$env:REPO_NAME"`), which then gets injected into the `DisplayInformationJSON` used by `build_vip.ps1`. This ensures each build is branded with your fork’s or org’s name.
+
+---
+
+### Q12: Can I Omit the Company/Author Fields in My JSON?
+
+**Answer**:
+Yes. If you don’t want to display them, pass empty strings (`-CompanyName "" -AuthorName ""`) or remove those fields from your script’s JSON object. The final `.vip` file will simply show blank lines or omit those entries.
+
+---
+
+### Q13: Why Must I Use Single-Dash Instead of Double-Dash?
+
+**Answer**:
+PowerShell **named parameters** typically start with a single dash (`-Parameter`). Double-dash syntax (`--param`) is common in Linux CLI tools but is not standard in a typical PowerShell `param()` declaration. If you try to pass `--arch` or `--lv-ver`, you’ll get an error about an unrecognized parameter.
+
+---
+
+### Q14: Can I Add More Fields to the VIPB Display Information?
+
+**Answer**:
+Absolutely. You can modify `$jsonObject` in your script to include new keys, such as `"Product Description"` or `"Special Internal ID"`. Just be sure that the VI that updates the `.vipb` file (`Modify_VIPB_Display_Information.vi`) knows how to handle those additional fields, or they might be ignored.
\ No newline at end of file
diff --git a/docs/manual-instructions.md b/docs/manual-instructions.md
new file mode 100644
index 00000000..417cada0
--- /dev/null
+++ b/docs/manual-instructions.md
@@ -0,0 +1,84 @@
+# Manual Setup & Editing Instructions
+
+This document provides **manual** steps to configure, edit, and distribute the LabVIEW Icon Editor source code without using PowerShell automation.
+
+---
+
+## Table of Contents
+
+1. [Compatible LabVIEW Versions](#compatible-labview-versions)
+2. [Editing Guide (Manual)](#editing-guide-manual)
+3. [Distribution Guide (Manual)](#distribution-guide-manual)
+
+---
+
+
+## 1. Compatible LabVIEW Versions
+
+- Source is saved in **LabVIEW 2021 SP1** format.
+- Both **LabVIEW 2021 SP1 (32-bit and 64-bit)** are typically required if you plan to build or distribute for both architectures.
+- Editing can be done on any LabVIEW version that can preserve the **2021** file format.
+
+---
+
+
+## 2. Editing Guide (Manual)
+
+1. **Clone** this repository to a development location, for example:
+
+ ```
+ C:\labview-icon-editor
+ ```
+
+2. **Run** the following VI to prepare your environment:
+
+ ```
+ Tooling\Prepare LV to Use Icon Editor Source.vi
+ ```
+
+ This VI will:
+ - Remove `\resource\plugins\lv_icon.lvlibp`
+ - Remove `\vi.lib\LabVIEW Icon API`
+ - Update `LocalHost.LibraryPaths` in your **LabVIEW.ini** so the custom VIs are recognized
+
+3. **Open** the project file:
+
+ ```
+ lv_icon_editor.lvproj
+ ```
+
+4. **Locate** the top-level VI inside the project:
+
+ ```
+ My Computer » resource/plugins » lv_icon.lvlib » lv_icon.vi
+ ```
+
+ You can now edit and develop the Icon Editor as needed.
+
+---
+
+
+## 3. Distribution Guide (Manual)
+
+To **manually distribute** your custom Icon Editor:
+
+1. **Build** the Packed Project Library (or .lvlibp):
+ - In LabVIEW, compile your top-level `lv_icon.lvlib` into a `.lvlibp` for deployment.
+
+2. **On the target machine**:
+ - Rename the default:
+
+ ```
+ \resource\plugins\lv_icon.lvlibp
+ ```
+ to:
+ ```
+ lv_icon.lvlibp.ship
+ ```
+ - Similarly archive or rename:
+ ```
+ \vi.lib\LabVIEW Icon API
+ ```
+ - **Copy** your newly built `lv_icon.lvlibp` and `vi.lib\LabVIEW Icon API\*` into the corresponding LabVIEW folders on the target machine.
+
+ You now have a custom, manually distributed Icon Editor that can support any LabVIEW version available up until the creation of this document.
diff --git a/docs/manual-setup.md b/docs/manual-setup.md
new file mode 100644
index 00000000..417cada0
--- /dev/null
+++ b/docs/manual-setup.md
@@ -0,0 +1,84 @@
+# Manual Setup & Editing Instructions
+
+This document provides **manual** steps to configure, edit, and distribute the LabVIEW Icon Editor source code without using PowerShell automation.
+
+---
+
+## Table of Contents
+
+1. [Compatible LabVIEW Versions](#compatible-labview-versions)
+2. [Editing Guide (Manual)](#editing-guide-manual)
+3. [Distribution Guide (Manual)](#distribution-guide-manual)
+
+---
+
+
+## 1. Compatible LabVIEW Versions
+
+- Source is saved in **LabVIEW 2021 SP1** format.
+- Both **LabVIEW 2021 SP1 (32-bit and 64-bit)** are typically required if you plan to build or distribute for both architectures.
+- Editing can be done on any LabVIEW version that can preserve the **2021** file format.
+
+---
+
+
+## 2. Editing Guide (Manual)
+
+1. **Clone** this repository to a development location, for example:
+
+ ```
+ C:\labview-icon-editor
+ ```
+
+2. **Run** the following VI to prepare your environment:
+
+ ```
+ Tooling\Prepare LV to Use Icon Editor Source.vi
+ ```
+
+ This VI will:
+ - Remove `\resource\plugins\lv_icon.lvlibp`
+ - Remove `\vi.lib\LabVIEW Icon API`
+ - Update `LocalHost.LibraryPaths` in your **LabVIEW.ini** so the custom VIs are recognized
+
+3. **Open** the project file:
+
+ ```
+ lv_icon_editor.lvproj
+ ```
+
+4. **Locate** the top-level VI inside the project:
+
+ ```
+ My Computer » resource/plugins » lv_icon.lvlib » lv_icon.vi
+ ```
+
+ You can now edit and develop the Icon Editor as needed.
+
+---
+
+
+## 3. Distribution Guide (Manual)
+
+To **manually distribute** your custom Icon Editor:
+
+1. **Build** the Packed Project Library (or .lvlibp):
+ - In LabVIEW, compile your top-level `lv_icon.lvlib` into a `.lvlibp` for deployment.
+
+2. **On the target machine**:
+ - Rename the default:
+
+ ```
+ \resource\plugins\lv_icon.lvlibp
+ ```
+ to:
+ ```
+ lv_icon.lvlibp.ship
+ ```
+ - Similarly archive or rename:
+ ```
+ \vi.lib\LabVIEW Icon API
+ ```
+ - **Copy** your newly built `lv_icon.lvlibp` and `vi.lib\LabVIEW Icon API\*` into the corresponding LabVIEW folders on the target machine.
+
+ You now have a custom, manually distributed Icon Editor that can support any LabVIEW version available up until the creation of this document.
diff --git a/docs/powershell-cli-github-action-instructions.md b/docs/powershell-cli-github-action-instructions.md
new file mode 100644
index 00000000..ed9f1a2a
--- /dev/null
+++ b/docs/powershell-cli-github-action-instructions.md
@@ -0,0 +1,358 @@
+# CI Workflow (Multi-Channel Release Support)
+
+This guide explains how to automate build, test, and distribution steps for the **LabVIEW Icon Editor** using GitHub Actions—**with multiple pre-release channels** (Alpha, Beta, RC), optional hotfix branches, and a toggleable **Development Mode** feature. It is designed to align with **Gitflow** practices, allowing you to enforce a hands-off approach where merges flow naturally from `develop` → `release-alpha` → `release-beta` → `release-rc` → `main`, while also ensuring forks can reuse the same build scripts.
+
+> **Note**: For **troubleshooting** and a more extensive **FAQ**, see the [TROUBLESHOOTING FAQ](ci/troubleshooting-faq.md). For more detailed runner setup instructions, see the [runner setup guide](ci/actions/runner-setup-guide.md)
+
+---
+
+## Table of Contents
+
+1. [Introduction](#1-introduction)
+2. [Quickstart / Step-by-Step Procedure](#2-quickstart--step-by-step-procedure)
+3. [Getting Started & Configuration](#3-getting-started--configuration)
+ 1. [Development Mode](#31-development-mode)
+ 2. [Environment Variables](#32-environment-variables)
+ 3. [Self-Hosted Runner Setup](#33-self-hosted-runner-setup)
+4. [Available CI Workflows](#4-available-ci-workflows)
+ 1. [Development Mode Toggle](#41-development-mode-toggle)
+ - [Overview](#411-overview)
+ - [Usage](#412-usage)
+ - [Examples: Calling This Workflow](#413-examples-calling-this-workflow)
+ - [Customization](#414-customization)
+ - [Additional Resources](#415-additional-resources)
+ 2. [Build VI Package](#42-build-vi-package)
+ 3. [Run Unit Tests](#43-run-unit-tests)
+5. [Gitflow Branching & Versioning](#5-gitflow-branching--versioning)
+ 1. [Branching Overview](#51-branching-overview)
+ 2. [Multi-Channel Pre-Releases](#52-multi-channel-pre-releases)
+ 3. [Hotfix Branches](#53-hotfix-branches)
+ 4. [Version Bumps via Labels](#54-version-bumps-via-labels)
+ 5. [Build Number](#55-build-number)
+6. [Branch Protection & Contributing](#6-branch-protection--contributing)
+7. [GPG Signing (Fork-Friendly)](#7-gpg-signing-fork-friendly)
+8. [External References](#8-external-references)
+
+---
+
+
+## 1. Introduction
+
+Automating your LabVIEW Icon Editor builds and releases offers several benefits:
+
+- **Gitflow alignment**: merges flow from feature → develop → (alpha/beta/rc) → main without manual toggles.
+- **Label-based semantic versioning** (`major`, `minor`, `patch`).
+- **Multiple pre-release channels** (Alpha/Beta/RC) via dedicated branch names.
+- **Commit-based build number** appended as `-build`.
+- **Hotfix branches** for urgent final patch releases.
+- **Fork-friendly GPG signing** toggles.
+- **Development Mode** toggle if you need LabVIEW to reference local source code directly for debugging.
+
+This workflow ensures that all **forks** of the repository can sync the latest build scripts from upstream (e.g., NI) and follow the same rules. If you keep your fork up to date, you benefit from any bug fixes or improvements made in the original repo.
+
+---
+
+
+## 2. Quickstart / Step-by-Step Procedure
+
+1. **Set up `.github/workflows`**
+ Ensure the following workflows exist (or adapt names as needed):
+ - `development-mode-toggle.yml` (Development Mode Toggle)
+ - `build-vi-package.yml` (Build VI Package)
+ - `run-unit-tests.yml` (Run Unit Tests)
+
+2. **Configure Permissions**
+ - In **Settings → Actions → General**, set **Workflow permissions** to “Read and write permissions” so the workflow can create tags and releases.
+
+3. **Check Environment Variables**
+ - Decide on `DRAFT_RELEASE`, `USE_AUTO_NOTES`, `ATTACH_ARTIFACTS_TO_RELEASE`, `DISABLE_GPG_ON_FORKS`, etc. (see [Environment Variables](#32-environment-variables)).
+
+4. **Make a Pull Request & Label It**
+ - Use labels `major`, `minor`, or `patch` if you need a version bump.
+ - If no label is found, only the build number increments.
+
+5. **Merge to the Appropriate Branch**
+ - In Gitflow, typical merges go from **feature** → **develop**, then eventually to:
+ - **`release-alpha/*`** for early testing (`-alpha.`),
+ - **`release-beta/*`** for later testing (`-beta.`),
+ - **`release-rc/*`** for near-final (`-rc.`),
+ - and finally **main** for a final release (no suffix).
+ - Alternatively, **`hotfix/*`** merges can go directly to **main** for quick patches.
+
+6. **Check Outputs and Releases**
+ - The `.vip` file is generated and uploaded as a build artifact.
+ - If `ATTACH_ARTIFACTS_TO_RELEASE == true`, it’s attached to the GitHub Release (draft by default).
+
+7. **Optionally Enable Development Mode**
+ - If you need LabVIEW to reference local source directly, run the **Development Mode Toggle** workflow (see [Development Mode](#31-development-mode)). Usually, you **disable** it for standard builds/tests.
+
+8. **Publish or Finalize the Release**
+ - If your release is drafted, you can edit notes and publish manually. Otherwise, it’s published immediately when `DRAFT_RELEASE == false`.
+
+For a visual reference, you may consult a **Gitflow diagram** that includes alpha/beta/rc branches as an extension of the typical `release/` branch. This helps illustrate how merges flow between `develop` and `main`.
+
+---
+
+
+## 3. Getting Started & Configuration
+
+
+### 3.1 Development Mode
+
+**Development Mode** configures LabVIEW for local debugging or specialized project setups. It often involves modifying `labview.ini` so LabVIEW references local source code. You can **enable** or **disable** it as needed:
+
+- **Enable**:
+ - Run the **Development Mode Toggle** workflow with `mode=enable` (or manually call `Set_Development_Mode.ps1`).
+- **Disable**:
+ - Run the workflow with `mode=disable` (or call `RevertDevelopmentMode.ps1`).
+
+> **Important**: When Development Mode is **enabled**, you generally can’t test the final `.vip` install properly (since LabVIEW might be pointing to local source). Always **disable** dev mode before attempting a final install or distribution test.
+
+
+### 3.2 Environment Variables
+
+Below are **common** environment variables you might configure:
+
+- **`DRAFT_RELEASE`** (default `true`):
+ - `true` → create a **draft** release (not published).
+ - `false` → publish immediately.
+- **`USE_AUTO_NOTES`** (default `true`):
+ - `true` → auto-generate release notes.
+- **`ATTACH_ARTIFACTS_TO_RELEASE`** (default `false`):
+ - `true` → attach the built `.vip` files to the release assets.
+- **`DISABLE_GPG_ON_FORKS`** (default `false`):
+ - `true` → disable GPG signing if running on a fork.
+
+
+### 3.3 Self-Hosted Runner Setup
+
+For **detailed runner configuration**, see **`runner-setup-guide.md`**. Below is a short summary:
+
+1. **Install Prerequisites**
+ - **LabVIEW 2021 SP1** (32-bit or 64-bit)
+ - **PowerShell 7+**
+ - **Git for Windows**
+2. **Add a Self-Hosted Runner**
+ - Go to **Settings → Actions → Runners**. Follow GitHub’s steps to register a Windows runner on your machine with LabVIEW installed.
+3. **Label Your Runner**
+ - For example, `self-hosted, iconeditor`. Ensure your workflow’s `runs-on` references these labels.
+
+---
+
+
+## 4. Available CI Workflows
+
+Below are the **three** key workflows. Each one is defined in its own `.yml` file.
+
+
+### 4.1 Development Mode Toggle
+
+You’ll typically name the workflow file **`development-mode-toggle.yml`**. Its purpose is to **enable** or **disable** a “development mode” on a self-hosted runner that has LabVIEW installed.
+
+
+#### 4.1.1 Overview
+
+**What Is “Development Mode”?**
+- A specialized state for LabVIEW-centric projects, where LabVIEW is configured to load code from local source paths (or apply certain debugging tokens in `labview.ini`).
+- This mode often prevents installing the final `.vip` for normal testing—so you’ll want to toggle it **off** once you finish coding or debugging.
+
+**Purpose of This Workflow**
+- Lets collaborators quickly switch a self-hosted runner into/out of dev mode.
+- Often triggered **manually** (via `workflow_dispatch`) or by other workflows (via `workflow_call`).
+- Simplifies toggling environment state without manual steps each time.
+
+
+#### 4.1.2 Usage
+
+1. **Trigger Manually**
+ - Go to the **Actions** tab, select the “Development Mode Toggle” workflow, click “Run workflow.”
+ - Choose `enable` or `disable` to run the corresponding PowerShell script (`Set_Development_Mode.ps1` or `RevertDevelopmentMode.ps1`).
+ - The workflow runs on your self-hosted runner (e.g., labeled `self-hosted, iconeditor`).
+
+2. **Important Note for Testing**
+ - With dev mode **enabled**, LabVIEW references local code, so installing the `.vip` may fail or cause conflicts.
+ - After coding, **disable** dev mode before building or testing the final package.
+
+3. **Trigger from Another Workflow**
+ - You can call this workflow using `workflow_call`. Pass the input parameter `mode` = `enable` or `disable`.
+ - The same runner used by the calling job is toggled accordingly.
+
+
+#### 4.1.3 Examples: Calling This Workflow
+
+**A) Call from Another Workflow in the Same Repository**
+```yaml
+name: "My Other Workflow"
+on:
+ workflow_dispatch:
+
+jobs:
+ call-dev-mode:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Invoke Dev Mode Toggle (enable)
+ uses: ./.github/workflows/development-mode-toggle.yml
+ with:
+ mode: enable
+```
+
+**B) Call from Another Repository**
+```yaml
+name: "Cross-Repo Dev Mode Toggle"
+on:
+ workflow_dispatch:
+
+jobs:
+ remote-dev-mode:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Use remote Dev Mode Toggle
+ uses: //.github/workflows/development-mode-toggle.yml@main
+ with:
+ mode: disable
+```
+
+**C) Call from a Fork**
+```yaml
+name: "Forked Dev Mode Example"
+on:
+ workflow_dispatch:
+
+jobs:
+ forked-workflow-call:
+ runs-on: [self-hosted, iconeditor]
+ steps:
+ - name: Call Dev Mode Toggle from My Fork
+ uses: //.github/workflows/development-mode-toggle.yml@my-feature-branch
+ with:
+ mode: enable
+```
+
+
+#### 4.1.4 Customization
+
+All dev-mode logic resides in two PowerShell scripts:
+
+- **`Set_Development_Mode.ps1`** – Called when mode is `enable`.
+- **`RevertDevelopmentMode.ps1`** – Called when mode is `disable`.
+
+
+#### 4.1.5 Additional Resources
+
+- Check your primary README or docs for LabVIEW setup details.
+- Official GitHub Docs on [Reusing workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows).
+
+---
+
+
+### 4.2 Build VI Package
+
+- **File Name**: `build-vi-package.yml`
+- **Purpose**: Builds the `.vip` artifact, determines the version based on PR labels and commit count, and optionally creates/releases the tag.
+- **Features**:
+ - **Label-based** version bump (`major`, `minor`, `patch`), or none if unlabeled.
+ - **Commit-based build number**: `vX.Y.Z-build` (plus optional pre-release suffix).
+ - **Multi-Channel** detection for `release-alpha/*`, `release-beta/*`, `release-rc/*`.
+ - **Fork-Friendly GPG**: Disabled if `DISABLE_GPG_ON_FORKS == true`.
+ - **Attach to Release** if `ATTACH_ARTIFACTS_TO_RELEASE == true`.
+- **Events**: Typically triggered on:
+ - Push or PR merge to `release-alpha/*`, `release-beta/*`, `release-rc/*`, `main`, and `hotfix/*`.
+ - Might also be triggered manually (`workflow_dispatch`) if needed.
+
+
+### 4.3 Run Unit Tests
+
+- **File Name**: `run-unit-tests.yml`
+- **Purpose**: Executes the Icon Editor’s unit tests (e.g., via `unit_tests.ps1`) in a **standard** LabVIEW environment (Dev Mode **disabled**).
+- **Usage**: Typically run on every pull request or push to validate code changes.
+- **Events**: Often triggered on PRs or pushes to `develop`, `feature/*`, or any branch being tested.
+
+---
+
+
+## 5. Gitflow Branching & Versioning
+
+
+### 5.1 Branching Overview
+
+**Gitflow** typically involves:
+- **`develop`**: main integration branch for ongoing development.
+- **`feature/*`**: branches off `develop` for individual features.
+- **`release/*`**: branched off `develop` when nearing release.
+- **`hotfix/*`**: branched off `main` for urgent fixes.
+
+In this repo, we extend the concept of `release/*` into **`release-alpha/*`, `release-beta/*`, and `release-rc/*`** to differentiate pre-release stages. Merges flow as:
+- **feature** → **develop** → **release-alpha/X.Y** → **release-beta/X.Y** → **release-rc/X.Y** → **main**.
+
+
+### 5.2 Multi-Channel Pre-Releases
+
+Branches named:
+- **`release-alpha/*`** → produces a version suffix `-alpha.`.
+- **`release-beta/*`** → produces a version suffix `-beta.`.
+- **`release-rc/*`** → produces a version suffix `-rc.`.
+
+Merging into these branches (or pushing directly to them) triggers a **pre-release build**. After final testing in `release-rc/*`, merging into **main** yields a stable release without any suffix.
+
+
+### 5.3 Hotfix Branches
+
+- **`hotfix/*`** merges produce a **final** release (no `-rc`, `-alpha`, or `-beta`).
+- Typically, you merge hotfix branches directly into **main** and then back into **develop** to keep them in sync.
+
+
+### 5.4 Version Bumps via Labels
+
+When you open a **Pull Request** into `develop`, `release-alpha/*`, or `release-beta/*` (or even `main`/`hotfix/*`):
+- A label of `major`, `minor`, or `patch` increments that segment of the version (e.g., `1.2.3` → `2.0.0` if `major`, etc.).
+- If **no** label is present, the major/minor/patch remains the same (only the build number increments).
+
+> **Note**: This means you can version-bump **incrementally** while merging into `develop` (to reflect that new features are in development), or you can wait until you merge to a pre-release branch. Each time the build runs, the resulting `.vip` has an updated version (with a new build number, plus any alpha/beta/rc suffix if applicable).
+
+
+### 5.5 Build Number
+
+- Determined by **`git rev-list --count HEAD`**.
+- Appended as `-build` in the final version string.
+- Always strictly the commit count—no overrides by default.
+
+---
+
+
+## 6. Branch Protection & Contributing
+
+In order to **enforce** the Gitflow approach “hands-off”:
+1. **Enable Branch Protection Rules**:
+ - For example, protect `main`, `release-alpha/*`, `release-beta/*`, and `release-rc/*` so that only approved Pull Requests can be merged, preventing direct pushes.
+ - Require checks (like “Build VI Package” or “Run Unit Tests”) to pass before merging.
+2. **Refer to `CONTRIBUTING.md`**:
+ - Document your team’s policies on how merges flow from feature → develop → alpha/beta/rc → main.
+ - Outline any required approvals or code reviews.
+
+> **Only the original (upstream) repo** typically **enforces** these rules. Forks may choose to adopt them but are not forced to. However, if you submit a PR **upstream**, you’ll need to comply with the branch protections in place there.
+
+---
+
+
+## 7. GPG Signing (Fork-Friendly)
+
+The workflows support **GPG signing** for tags and releases in the **main** repository. However, on forks you often lack the GPG key/passphrase. To avoid blocking prompts:
+
+- **`DISABLE_GPG_ON_FORKS = true`** automatically **disables** signing if the workflow detects it’s running on a fork.
+- If you’re in the **main** repo and have GPG keys set up, signing remains **enabled**.
+
+This ensures forks can build without requiring special key setup, while the main repository can maintain secure signing.
+
+---
+
+
+## 8. External References
+
+- **Multi-Channel Logic**: See [docs/ci/actions/multichannel-release-workflow.md](docs/ci/actions/multichannel-release-workflow.md) for deeper details on alpha, beta, and RC release strategies.
+- **Runner Setup**: For an in-depth guide on configuring your environment, see **`runner-setup-guide.md`**.
+- **Troubleshooting & FAQ**: See **TROUBLESHOOTING_AND_FAQ.md** (or your chosen file name) for a detailed list of common issues, solutions, and frequently asked questions.
+- **Contributing**: For main-merge rules, code review guidelines, and other policies, see **`CONTRIBUTING.md`**.
+- **Gitflow Diagram**: [Atlassian Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) or any other standard resource to visualize the overall branching approach (extended with alpha/beta/rc branches).
+
+---
+
diff --git a/docs/powershell-cli-instructions.md b/docs/powershell-cli-instructions.md
new file mode 100644
index 00000000..50dc63be
--- /dev/null
+++ b/docs/powershell-cli-instructions.md
@@ -0,0 +1,208 @@
+# Powershell Command Line Interface Instructions
+
+This document describes how to **build, test, and distribute** the **LabVIEW Icon Editor** VI Package using **PowerShell**. You can run these scripts locally on your development or self-hosted runner, or within **GitHub Actions**. By making this process open source, we enable community collaboration, easier troubleshooting, and a more transparent build pipeline for the Icon Editor that ships with LabVIEW.
+
+## Table of Contents
+
+1. [Overview & Prerequisites](#overview--prerequisites)
+2. [Editing Guide (PowerShell)](#editing-guide-powershell)
+3. [Distribution Guide (VI Package via PowerShell)](#distribution-guide-vi-package-via-powershell)
+4. [Integrating with GitHub Actions](#integrating-with-github-actions)
+5. [How `Build.ps1` Works](#how-buildps1-works)
+6. [Local vs. CI Usage](#local-vs-ci-usage)
+7. [Example Developer Workflow](#example-developer-workflow)
+
+---
+
+
+## 1. Overview & Prerequisites
+
+- **Purpose**: Provide a **PowerShell-centric** approach to build, test, and package the Icon Editor—either locally or via GitHub Actions.
+- **Why PowerShell?**
+ - Simplifies applying VIPCs, building `.lvlibp`, and producing a `.vip` artifact.
+ - Lets you debug locally using the **exact same scripts** used in CI, ensuring consistent results between local and automated environments.
+
+- **Prerequisites**:
+ 1. **LabVIEW 2021 SP1 (both 32-bit & 64-bit)**.
+ 2. **PowerShell 7+** and **Git**.
+ 3. **Apply** `tooling\deployment\runner_dependencies.vipc` to **both 32-bit & 64-bit LabVIEW**.
+
+---
+
+
+## 2. Editing Guide (PowerShell)
+
+1. **Back Up** (highly recommended):
+ - `\resource\plugins\lv_icon.lvlibp`
+ - `\vi.lib\LabVIEW Icon API`
+
+2. **Clone** the [Icon Editor](https://github.com/ni/labview-icon-editor.git) to your development location.
+
+3. **Apply** dependencies:
+ - `Tooling\deployment\runner_dependencies.vipc` to **LabVIEW 2021 (32-bit) & LabVIEW 2021 (64-bit)**.
+
+4. **Open** PowerShell (Admin), navigate to your working directory:
+ ```
+ pipeline\scripts
+ ```
+
+5. **Enable Dev Mode**:
+ ```powershell
+ .\Set_Development_Mode.ps1 -RelativePath "C:\labview-icon-editor"
+ ```
+ Removes the default `lv_icon.lvlibp` and points LabVIEW to your local Icon Editor code.
+
+6. **Open** the project:
+ ```
+ lv_icon_editor.lvproj
+ ```
+ Edit the Icon Editor source as needed.
+
+---
+
+
+## 3. Distribution Guide (VI Package via PowerShell)
+
+### Why & How for Branding the Package
+
+When distributing your own fork or build of the Icon Editor, you may want to **uniquely brand** your `.vip` package with your **organization** and **repository** information (or any other metadata). This ensures:
+- **Unique identification** if multiple organizations produce their own variants of the Editor.
+- **Easier troubleshooting** by embedding your org/repo directly in the final VI Package metadata.
+
+You can do so by passing metadata fields (like `-CompanyName` and `-AuthorName`) to the `Build.ps1` script. These are then injected into the final **DisplayInformationJSON** (see Section [How `Build.ps1` Works](#how-buildps1-works)).
+
+### Steps to Build/Distribute
+
+1. **Apply Dependencies** in VIPM:
+ - Set LabVIEW to **2021 (32-bit)**, apply `Tooling\deployment\runner_dependencies.vipc`.
+ - Repeat for **64-bit** if necessary.
+
+2. **Disable LabVIEW Security Warnings** (to prevent popups from "run when opened" VIs):
+ - **Tools → Options → Security** → **Run VI Without Warnings**.
+
+3. **Open** PowerShell (Admin), navigate to:
+ ```
+ pipeline\scripts
+ ```
+
+4. **Run** `Build.ps1` (with optional brand info):
+ ```powershell
+ .\Build.ps1 `
+ -RelativePath "C:\labview-icon-editor" `
+ -AbsolutePathScripts "C:\labview-icon-editor\pipeline\scripts" `
+ -Major 1 -Minor 2 -Patch 3 -Build 45 `
+ -Commit "my-commit-sha" `
+ -LabVIEWMinorRevision 3 `
+ -CompanyName "Acme Inc." `
+ -AuthorName "acme-inc/lv-icon-editor" `
+ -Verbose
+ ```
+ This generates a `.vip` in `builds\VI Package`. Your **organization** and **repo** details appear in the final package, helping brand your build uniquely.
+
+5. **Revert Dev Mode (optional)**:
+ ```powershell
+ .\RevertDevelopmentMode.ps1 -RelativePath "C:\labview-icon-editor"
+ ```
+
+6. **Install** the `.vip` in VIPM (as Admin), validate your custom Icon Editor changes.
+
+---
+
+
+## 4. Integrating with GitHub Actions
+
+We provide **GitHub Actions** that wrap these same PowerShell scripts for building the Icon Editor. You can also pass **metadata** (e.g., repository or organization) directly via environment variables or YAML inputs:
+
+```yaml
+name: Build LabVIEW Icon Editor
+on:
+ push:
+ branches: [ "main" ]
+
+jobs:
+ build:
+ runs-on: windows-latest
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v3
+
+ - name: Setup PowerShell
+ uses: actions/setup-powershell@v2
+
+ - name: Build Script
+ run: |
+ pwsh .\Build.ps1 `
+ -RelativePath "$env:GITHUB_WORKSPACE" `
+ -AbsolutePathScripts "$env:GITHUB_WORKSPACE\pipeline\scripts" `
+ -Major 1 -Minor 2 -Patch 3 -Build 45 `
+ -Commit "${{ github.sha }}" `
+ -LabVIEWMinorRevision 3 `
+ -CompanyName "${{ github.repository_owner }}" `
+ -AuthorName "${{ github.repository }}" `
+ -Verbose
+```
+
+**Key Points**:
+- `-CompanyName "${{ github.repository_owner }}"` ensures the package shows your org/user name.
+- `-AuthorName "${{ github.repository }}"` can embed the “repo” portion, e.g. `my-org/lv-icon-editor`.
+- The rest of the steps (applying VIPC, building the libraries) run identically to local usage, ensuring **consistency**.
+
+---
+
+
+## 5. How `Build.ps1` Works
+
+`Build.ps1` orchestrates the entire build:
+
+1. **Clean**: Removes old `.lvlibp` files in `resource\plugins`.
+2. **Apply VIPC**: For **32-bit** & **64-bit** LabVIEW, ensuring all dependencies are set.
+3. **Build**: Invokes `Build_lvlibp.ps1` to produce `.lvlibp` files for both bitnesses, injecting version info (`-Major -Minor -Patch -Build`) and a `-Commit`.
+4. **Rename**: Moves them to `lv_icon_x86.lvlibp` and `lv_icon_x64.lvlibp`.
+5. **Construct DisplayInformationJSON**:
+ - Merges any metadata fields you pass in (e.g., **`-CompanyName`, `-AuthorName`**) so that the final `.vip` is **branded**.
+ - Also includes your version data in `"Package Version"`.
+6. **Call `build_vip.ps1`**:
+ - This script reads the JSON, modifies the `.vipb`, and builds the final **VI Package** with `g-cli`.
+ - The optional `-LabVIEWMinorRevision` param can override default minor version logic (e.g., 21.3).
+7. **Close LabVIEW** (64-bit) after the build is done.
+
+**Result**: A `.vip` file containing your version, commit, and brand/metadata in the Display Information fields.
+
+---
+
+
+## 6. Local vs. CI Usage
+
+1. **Local**:
+ - You can pass custom `-CompanyName` and `-AuthorName` directly on the PowerShell command line.
+ - For example, to brand the build “AcmeCorp” from “AcmeCorp/lv-icon-editor.”
+
+2. **CI (GitHub Actions)**:
+ - Exactly the same script runs. The difference is that environment variables (like `${{ github.repository_owner }}`) feed into `-CompanyName`, etc.
+ - This way, each fork or org can produce a uniquely identified package.
+
+---
+
+
+## 7. Example Developer Workflow
+
+1. **Enable Dev Mode**
+ ```powershell
+ .\Set_Development_Mode.ps1 -RelativePath "C:\labview-icon-editor"
+ ```
+2. **Develop & Test**
+ - You can open `lv_icon_editor.lvproj`, make changes, and run `Run_Unit_Tests.ps1`.
+3. **Open PR**
+ - Mark your PR with semver changes (major/minor/patch).
+ - GitHub Actions picks it up, calls `Build.ps1`.
+4. **Build**
+ - The resulting `.vip` is attached to releases or stored as an artifact, showing your **version** and **branding** (company/repo).
+5. **Disable Dev Mode** (optional)
+ ```powershell
+ .\RevertDevelopmentMode.ps1 -RelativePath "C:\labview-icon-editor"
+ ```
+6. **Install**
+ - Use VIPM to install the final `.vip` and confirm changes.
+
+All scripts are fully open source—**collaborators** can debug or extend them locally with minimal friction.
+
diff --git a/lv_icon_editor.lvproj b/lv_icon_editor.lvproj
index b6fbf1aa..6ad83ca1 100644
--- a/lv_icon_editor.lvproj
+++ b/lv_icon_editor.lvproj
@@ -18,289 +18,288 @@
-
-
-
-
+
-
-
-
+
-
+
-
-
+
-
-
+
-
-
+
-
-
-
+
+
-
+
-
-
+
+
-
-
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
+
+
+
-
-
+
+
-
+
-
-
-
-
-
+
+
+
+
+
-
-
-
-
+
+
+
+
-
+
-
-
+
-
-
-
-
+
+
-
-
+
-
-
-
-
-
-
-
+
+
+
+
+
+
-
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
-
-
-
-
+
+
+
-
-
-
-
-
+
+
+
+
+
-
+
-
-
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
+
+
+
+
+
-
-
-
-
-
-
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
+
+
+
+
+
+
-
-
-
-
+
+
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
-
-
-
-
-
-
+
+
+
+
+
-
-
+
-
-
-
-
-
-
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
-
-
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
+
+
-
-
-
+
+
+
-
-
+
@@ -308,9 +307,9 @@
-
+
-
+
-
@@ -322,326 +321,249 @@
-
-
-
-
+ -
+
+
+ -
+
-
-
-
-
-
-
-
-
-
-
+
-
-
+
-
-
+
-
-
+
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
-
-
+
-
+
-
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
-
-
-
-
-
-
+
+
+
-
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
+
+
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
-
-
true
-
- -
+
-
true
-
- -
+
-
true
+
+
+
+
-
-
-
+
+
+
-
-
-
+
+
-
-
@@ -656,7 +578,7 @@
true
/My Computer/Tooling/Pre Build Icon Editor PPL.vi
{C699D48A-6A0A-4A55-BF6A-D6FC254001CD}
- 14
+ 1
1
lv_icon.lvlibp
../resource/plugins/lv_icon.lvlibp
@@ -668,7 +590,7 @@
relativeToProject
2
true
- {DF18F03D-AB3A-4A60-8CAC-2585657B8F29}
+ {138797B9-53A9-4873-9DF2-49472334A11F}
Container
0
/My Computer/resource\/plugins/lv_icon.lvlib
@@ -708,6 +630,10 @@
/My Computer/vi.lib\/LabVIEW Icon API/LabVIEW Icon API.lvlib/Controls
Include
Container
+ 0
+ /My Computer/resource\/plugins/NIIconEditor/Miscellaneous/Graphics/LoadGraphics.vi
+ Include
+ VI
0
/My Computer/vi.lib\/LabVIEW Icon API/LabVIEW Icon API.lvlib
true
@@ -741,7 +667,7 @@
/My Computer/vi.lib\/LabVIEW Icon API/LabVIEW Icon API.lvlib/Set VI Icon.vi
Include
VI
- 17
+ 18
National Instruments
Icon Editor Packed Library
Icon Editor Packed Library
diff --git a/pipeline/scripts/ApplyVIPC.ps1 b/pipeline/scripts/ApplyVIPC.ps1
index db57bc51..c51ed18a 100644
--- a/pipeline/scripts/ApplyVIPC.ps1
+++ b/pipeline/scripts/ApplyVIPC.ps1
@@ -1,7 +1,14 @@
-# Example Usage:
-# .\Applyvipc.ps1 -MinimumSupportedLVVersion "2021" -SupportedBitness "64" -RelativePath "C:\labview-icon-editor" -VIPCPath "Tooling\deployment\Dependencies.vipc" -VIP_LVVersion "2021"
+<#
+.SYNOPSIS
+ Applies a .vipc file to a given LabVIEW version/bitness.
+ This version includes additional debug/verbose output.
-param (
+.EXAMPLE
+ .\applyvipc.ps1 -MinimumSupportedLVVersion "2021" -SupportedBitness "64" -RelativePath "C:\labview-icon-editor-fork" -VIPCPath "Tooling\deployment\Dependencies.vipc" -VIP_LVVersion "2021" -Verbose
+#>
+
+[CmdletBinding()] # Enables -Verbose and other common parameters
+Param (
[string]$MinimumSupportedLVVersion,
[string]$VIP_LVVersion,
[string]$SupportedBitness,
@@ -9,78 +16,111 @@ param (
[string]$VIPCPath
)
-if ($VIP_LVVersion -eq "2021" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_A = "21.0 (64-bit)"
-} elseif ($VIP_LVVersion -eq "2021" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_A = "21.0"
-} elseif ($VIP_LVVersion -eq "2022" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_A = "22.3 (64-bit)"
-} elseif ($VIP_LVVersion -eq "2022" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_A = "22.3"
-} elseif ($VIP_LVVersion -eq "2023" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_A = "23.3 (64-bit)"
-} elseif ($VIP_LVVersion -eq "2023" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_A = "23.3"
-} elseif ($VIP_LVVersion -eq "2024" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_A = "24.3 (64-bit)"
-} elseif ($VIP_LVVersion -eq "2024" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_A = "24.3"
-} else {
- Write-Output "Unsupported VIP_LVVersion or SupportedBitness"
- exit 1
-}
+Write-Verbose "Script Name: $($MyInvocation.MyCommand.Definition)"
+Write-Verbose "Parameters provided:"
+Write-Verbose " - MinimumSupportedLVVersion: $MinimumSupportedLVVersion"
+Write-Verbose " - VIP_LVVersion: $VIP_LVVersion"
+Write-Verbose " - SupportedBitness: $SupportedBitness"
+Write-Verbose " - RelativePath: $RelativePath"
+Write-Verbose " - VIPCPath: $VIPCPath"
+
+# -------------------------
+# 1) Resolve Paths & Validate
+# -------------------------
+try {
+ Write-Verbose "Attempting to resolve the 'RelativePath'..."
+ $ResolvedRelativePath = Resolve-Path -Path $RelativePath -ErrorAction Stop
+ Write-Verbose "ResolvedRelativePath: $ResolvedRelativePath"
-if ($MinimumSupportedLVVersion -eq "2021" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_B = "21.0 (64-bit)"
-} elseif ($MinimumSupportedLVVersion -eq "2021" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_B = "21.0"
-} elseif ($MinimumSupportedLVVersion -eq "2022" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_B = "22.3 (64-bit)"
-} elseif ($MinimumSupportedLVVersion -eq "2022" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_B = "22.3"
-} elseif ($MinimumSupportedLVVersion -eq "2023" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_B = "23.3 (64-bit)"
-} elseif ($MinimumSupportedLVVersion -eq "2023" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_B = "23.3"
-} elseif ($MinimumSupportedLVVersion -eq "2024" -and $SupportedBitness -eq "64") {
- $VIP_LVVersion_B = "24.3 (64-bit)"
-} elseif ($MinimumSupportedLVVersion -eq "2024" -and $SupportedBitness -eq "32") {
- $VIP_LVVersion_B = "24.3"
-} else {
- Write-Output "Unsupported MinimumSupportedLVVersion or SupportedBitness"
+ Write-Verbose "Building full path for the .vipc file..."
+ $ResolvedVIPCPath = Join-Path -Path $ResolvedRelativePath -ChildPath $VIPCPath -ErrorAction Stop
+ Write-Verbose "ResolvedVIPCPath: $ResolvedVIPCPath"
+
+ # Verify that the .vipc file actually exists
+ Write-Verbose "Checking if the .vipc file exists at the resolved path..."
+ if (-not (Test-Path $ResolvedVIPCPath)) {
+ Write-Error "The .vipc file does not exist at '$ResolvedVIPCPath'."
+ exit 1
+ }
+ Write-Verbose "The .vipc file was found successfully."
+}
+catch {
+ Write-Error "Error resolving paths. Ensure RelativePath and VIPCPath are valid. Details: $($_.Exception.Message)"
exit 1
}
-function Execute-GCLICommand {
- param (
- [string]$Command
- )
-
- Write-Output "Executing: $Command"
- Invoke-Expression $Command
+# -------------------------
+# 2) Build LabVIEW Version Strings
+# -------------------------
+Write-Verbose "Determining LabVIEW version strings..."
+switch ("$VIP_LVVersion-$SupportedBitness") {
+ "2021-64" { $VIP_LVVersion_A = "21.0 (64-bit)" }
+ "2021-32" { $VIP_LVVersion_A = "21.0" }
+ "2022-64" { $VIP_LVVersion_A = "22.3 (64-bit)" }
+ "2022-32" { $VIP_LVVersion_A = "22.3" }
+ "2023-64" { $VIP_LVVersion_A = "23.3 (64-bit)" }
+ "2023-32" { $VIP_LVVersion_A = "23.3" }
+ "2024-64" { $VIP_LVVersion_A = "24.3 (64-bit)" }
+ "2024-32" { $VIP_LVVersion_A = "24.3" }
+ default {
+ Write-Error "Unsupported VIP_LVVersion or SupportedBitness for VIP_LVVersion_A."
+ exit 1
+ }
+}
- if ($LASTEXITCODE -ne 0) {
- Write-Error "Command failed: $Command"
- exit $LASTEXITCODE
+switch ("$MinimumSupportedLVVersion-$SupportedBitness") {
+ "2021-64" { $VIP_LVVersion_B = "21.0 (64-bit)" }
+ "2021-32" { $VIP_LVVersion_B = "21.0" }
+ "2022-64" { $VIP_LVVersion_B = "22.3 (64-bit)" }
+ "2022-32" { $VIP_LVVersion_B = "22.3" }
+ "2023-64" { $VIP_LVVersion_B = "23.3 (64-bit)" }
+ "2023-32" { $VIP_LVVersion_B = "23.3" }
+ "2024-64" { $VIP_LVVersion_B = "24.3 (64-bit)" }
+ "2024-32" { $VIP_LVVersion_B = "24.3" }
+ default {
+ Write-Error "Unsupported MinimumSupportedLVVersion or SupportedBitness for VIP_LVVersion_B."
+ exit 1
}
}
-Write-Output "Applying dependencies for $VIP_LVVersion_B"
+Write-Output "Applying dependencies for LabVIEW $VIP_LVVersion_B..."
+Write-Verbose "VIP_LVVersion_A (for primary LVVersion): $VIP_LVVersion_A"
+Write-Verbose "VIP_LVVersion_B (for minimum LVVersion): $VIP_LVVersion_B"
-$command1 = "g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness -v `"$RelativePath\Tooling\Deployment\Applyvipc.vi`" -- `"$RelativePath\$VIPCPath`" `"$VIP_LVVersion_B`""
-Execute-GCLICommand -Command $command1
+# -------------------------
+# 3) Construct the Script to Execute
+# -------------------------
+Write-Verbose "Constructing the g-cli command script..."
+$script = @"
+g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness -v "$($ResolvedRelativePath)\Tooling\Deployment\Applyvipc.vi" -- "$ResolvedVIPCPath" "$VIP_LVVersion_B"
+g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness -v "$($ResolvedRelativePath)\Tooling\Deployment\Applyvipc.vi" -- "$ResolvedVIPCPath" "$VIP_LVVersion_B"
+"@
if ($VIP_LVVersion -ne $MinimumSupportedLVVersion) {
- Write-Output "Switching versions to apply dependencies for $VIP_LVVersion_A"
-
- $command2 = "g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness -v QuitLabVIEW"
- Execute-GCLICommand -Command $command2
-
- $command3 = "g-cli --lv-ver $VIP_LVVersion --arch $SupportedBitness -v `"$RelativePath\Tooling\Deployment\Applyvipc.vi`" -- `"$RelativePath\$VIPCPath`" `"$VIP_LVVersion_A`""
- Execute-GCLICommand -Command $command3
+ Write-Verbose "VIP_LVVersion and MinimumSupportedLVVersion differ; adding commands for $VIP_LVVersion..."
+ $script += @"
+g-cli --lv-ver $VIP_LVVersion --arch $SupportedBitness -v "$($ResolvedRelativePath)\Tooling\Deployment\Applyvipc.vi" -- "$ResolvedVIPCPath" "$VIP_LVVersion_A"
+g-cli --lv-ver $VIP_LVVersion --arch $SupportedBitness -v "$($ResolvedRelativePath)\Tooling\Deployment\Applyvipc.vi" -- "$ResolvedVIPCPath" "$VIP_LVVersion_A"
+"@
}
-$command4 = "g-cli --lv-ver $VIP_LVVersion --arch $SupportedBitness -v QuitLabVIEW"
-Execute-GCLICommand -Command $command4
+# -------------------------
+# 4) Output the script for debugging
+# -------------------------
+Write-Output "Executing the following commands:"
+Write-Output $script
+Write-Verbose "Full script content (for debugging): `n$script"
-Write-Host "Apply dependencies to LabVIEW $MinimumSupportedLVVersion ($SupportedBitness-bit)"
+# -------------------------
+# 5) Execute the Script & Handle Errors (Try/Catch with Invoke-Expression)
+# -------------------------
+try {
+ Write-Verbose "Starting Invoke-Expression to run g-cli commands..."
+ Invoke-Expression $script
+ Write-Host "Successfully applied dependencies to LabVIEW: $VIP_LVVersion_B" `
+ " (and potentially $VIP_LVVersion_A if switched)."
+}
+catch {
+ Write-Error "An error occurred while applying the .vipc dependencies. Details: $($_.Exception.Message)"
+ exit 1
+}
diff --git a/pipeline/scripts/Build.ps1 b/pipeline/scripts/Build.ps1
index d07b7519..c8dbced0 100644
--- a/pipeline/scripts/Build.ps1
+++ b/pipeline/scripts/Build.ps1
@@ -1,112 +1,245 @@
-# .\Build.ps1 -RelativePath "C:\labview-icon-editor" -AbsolutePathScripts "C:\labview-icon-editor\pipeline\scripts"
+<#
+.SYNOPSIS
+ This script automates the build process for the LabVIEW Icon Editor project.
+ It performs the following tasks:
+ 1. Cleans up old .lvlibp files in the plugins folder.
+ 2. Applies VIPC (32-bit and 64-bit).
+ 3. Builds the LabVIEW library (32-bit and 64-bit).
+ 4. Closes LabVIEW (32-bit and 64-bit).
+ 5. Renames the built files.
+ 6. Builds the VI package (64-bit) with DisplayInformationJSON fields.
+ 7. Closes LabVIEW (64-bit).
+
+ Example usage:
+ .\Build.ps1 `
+ -RelativePath "C:\labview-icon-editor-fork" `
+ -AbsolutePathScripts "C:\labview-icon-editor-fork\pipeline\scripts" `
+ -Major 1 -Minor 0 -Patch 0 -Build 0 -Commit "Placeholder" `
+ -CompanyName "Acme Corporation" `
+ -AuthorName "John Doe (Acme Corp)" `
+ -Verbose
+#>
+
+[CmdletBinding()] # Enables -Verbose, -Debug, etc.
param(
[Parameter(Mandatory = $true)]
[string]$RelativePath,
-
+
+ [Parameter(Mandatory = $true)]
+ [string]$AbsolutePathScripts,
+
+ [Parameter(Mandatory = $true)]
+ [int]$Major = 1,
+
+ [Parameter(Mandatory = $true)]
+ [int]$Minor,
+
+ [Parameter(Mandatory = $true)]
+ [int]$Patch,
+
[Parameter(Mandatory = $true)]
- [string]$AbsolutePathScripts
+ [int]$Build,
+
+ [Parameter(Mandatory = $true)]
+ [string]$Commit,
+
+ # LabVIEW "minor" revision (0 or 3)
+ [Parameter(Mandatory = $false)]
+ [int]$LabVIEWMinorRevision = 3,
+
+ # New parameters that will populate the JSON fields
+ [Parameter(Mandatory = $true)]
+ [string]$CompanyName,
+
+ [Parameter(Mandatory = $true)]
+ [string]$AuthorName
)
-# Helper function to check for file or directory existence
+# Helper function to verify a file/folder path exists
function Assert-PathExists {
param(
[string]$Path,
[string]$Description
)
- if (-Not (Test-Path -Path $Path)) {
- Write-Host "The $Description does not exist: $Path" -ForegroundColor Red
+ Write-Verbose "Checking if '$Description' exists at path: $Path"
+ if (-not (Test-Path -Path $Path)) {
+ Write-Host "The '$Description' does not exist: $Path" -ForegroundColor Red
exit 1
}
+ Write-Verbose "Confirmed '$Description' exists at path: $Path"
}
-# Helper function to execute scripts sequentially
+# Helper function to run another script with arguments
function Execute-Script {
param(
[string]$ScriptPath,
[string]$Arguments
)
Write-Host "Executing: $ScriptPath $Arguments" -ForegroundColor Cyan
+ Write-Verbose "Constructing command line..."
+
+ # The & symbol explicitly invokes the script file
+ $command = "& `"$ScriptPath`" $Arguments"
+ Write-Verbose "Command: $command"
+
try {
- # Build and execute the command
- $command = "& `"$ScriptPath`" $Arguments"
Invoke-Expression $command
-
- # Check for errors in the script execution
+ Write-Verbose "Command completed. Checking exit code..."
if ($LASTEXITCODE -ne 0) {
- Write-Host "Error occurred while executing: $ScriptPath with arguments: $Arguments. Exit code: $LASTEXITCODE" -ForegroundColor Red
+ Write-Host "Error occurred while executing: `"$ScriptPath`" with arguments: `"$Arguments`". Exit code: $LASTEXITCODE" -ForegroundColor Red
exit $LASTEXITCODE
}
- } catch {
- Write-Host "Error occurred while executing: $ScriptPath with arguments: $Arguments. Exiting." -ForegroundColor Red
+ Write-Verbose "Exit code is 0; no errors detected."
+ }
+ catch {
+ Write-Host "Error occurred while executing: `"$ScriptPath`" with arguments: `"$Arguments`". Exiting." -ForegroundColor Red
+ Write-Verbose "Exception details: $($_.Exception.Message)"
exit 1
}
}
-# Main script logic
try {
- # Validate required paths
+ Write-Verbose "Script: Build.ps1 starting."
+ Write-Verbose "Parameters received:"
+ Write-Verbose " - RelativePath: $RelativePath"
+ Write-Verbose " - AbsolutePathScripts: $AbsolutePathScripts"
+ Write-Verbose " - Major: $Major"
+ Write-Verbose " - Minor: $Minor"
+ Write-Verbose " - Patch: $Patch"
+ Write-Verbose " - Build: $Build"
+ Write-Verbose " - Commit: $Commit"
+ Write-Verbose " - LabVIEWMinorRevision: $LabVIEWMinorRevision"
+ Write-Verbose " - CompanyName: $CompanyName"
+ Write-Verbose " - AuthorName: $AuthorName"
+
+ # Validate needed folders
Assert-PathExists $RelativePath "RelativePath"
Assert-PathExists "$RelativePath\resource\plugins" "Plugins folder"
Assert-PathExists $AbsolutePathScripts "Scripts folder"
- # Clean up .lvlibp files in the plugins folder
+ # 1) Clean up old .lvlibp in the plugins folder
Write-Host "Cleaning up old .lvlibp files in plugins folder..." -ForegroundColor Yellow
- $PluginFiles = Get-ChildItem -Path "$RelativePath\resource\plugins" -Filter '*.lvlibp' -ErrorAction SilentlyContinue
- if ($PluginFiles) {
- $PluginFiles | Remove-Item -Force
- Write-Host "Deleted .lvlibp files from plugins folder." -ForegroundColor Green
- } else {
- Write-Host "No .lvlibp files found to delete." -ForegroundColor Cyan
+ Write-Verbose "Looking for .lvlibp files in $($RelativePath)\resource\plugins..."
+ try {
+ $PluginFiles = Get-ChildItem -Path "$RelativePath\resource\plugins" -Filter '*.lvlibp' -ErrorAction Stop
+ if ($PluginFiles) {
+ Write-Verbose "Found $($PluginFiles.Count) file(s): $($PluginFiles | ForEach-Object { $_.Name } -join ', ')"
+ $PluginFiles | Remove-Item -Force
+ Write-Host "Deleted .lvlibp files from plugins folder." -ForegroundColor Green
+ }
+ else {
+ Write-Host "No .lvlibp files found to delete." -ForegroundColor Cyan
+ }
+ }
+ catch {
+ Write-Host "Error occurred while retrieving .lvlibp files: $($_.Exception.Message)" -ForegroundColor Red
+ Write-Verbose "Stack Trace: $($_.Exception.StackTrace)"
}
- # Set development mode
-
- # Apply dependencies for LV 2021
- Execute-Script "$($AbsolutePathScripts)\Applyvipc.ps1" `
- "-MinimumSupportedLVVersion 2021 -SupportedBitness 32 -RelativePath `"$RelativePath`" -VIPCPath `"Tooling\deployment\Dependencies.vipc`" -VIP_LVVersion 2021"
-
- # Run Unit Tests
- Execute-Script "$($AbsolutePathScripts)\RunUnitTests.ps1" `
- "-MinimumSupportedLVVersion 2021 -SupportedBitness 32 -RelativePath `"$RelativePath`""
- # Build LV Library
+ # 2) Apply VIPC (32-bit)
+ Write-Verbose "Now applying VIPC for 32-bit..."
+ Execute-Script "$($AbsolutePathScripts)\ApplyVIPC.ps1" `
+ ("-MinimumSupportedLVVersion 2021 " +
+ "-VIP_LVVersion 2021 " +
+ "-SupportedBitness 32 " +
+ "-RelativePath `"$RelativePath`" " +
+ "-VIPCPath `"Tooling\deployment\Dependencies.vipc`"")
+
+ # 3) Build LV Library (32-bit)
+ Write-Verbose "Building LV library (32-bit)..."
Execute-Script "$($AbsolutePathScripts)\Build_lvlibp.ps1" `
- "-MinimumSupportedLVVersion 2021 -SupportedBitness 32 -RelativePath `"$RelativePath`""
-
-
- # Close LabVIEW
+ ("-MinimumSupportedLVVersion 2021 " +
+ "-SupportedBitness 32 " +
+ "-RelativePath `"$RelativePath`" " +
+ "-Major $Major -Minor $Minor -Patch $Patch -Build $Build " +
+ "-Commit `"$Commit`"")
+
+ # 4) Close LabVIEW (32-bit)
+ Write-Verbose "Closing LabVIEW (32-bit)..."
Execute-Script "$($AbsolutePathScripts)\Close_LabVIEW.ps1" `
"-MinimumSupportedLVVersion 2021 -SupportedBitness 32"
- # Rename the file after build
+ # 5) Rename .lvlibp -> lv_icon_x86.lvlibp
+ Write-Verbose "Renaming .lvlibp file to lv_icon_x86.lvlibp..."
Execute-Script "$($AbsolutePathScripts)\Rename-File.ps1" `
"-CurrentFilename `"$RelativePath\resource\plugins\lv_icon.lvlibp`" -NewFilename 'lv_icon_x86.lvlibp'"
-
- # Apply dependencies for LV 2021
- Execute-Script "$($AbsolutePathScripts)\Applyvipc.ps1" `
- "-MinimumSupportedLVVersion 2021 -SupportedBitness 64 -RelativePath `"$RelativePath`" -VIPCPath `"Tooling\deployment\Dependencies.vipc`" -VIP_LVVersion 2021"
- # Run Unit Tests
- Execute-Script "$($AbsolutePathScripts)\RunUnitTests.ps1" `
- "-MinimumSupportedLVVersion 2021 -SupportedBitness 64 -RelativePath `"$RelativePath`""
-
- # Build LV Library
+ # 6) Apply VIPC (64-bit)
+ Write-Verbose "Now applying VIPC for 64-bit..."
+ Execute-Script "$($AbsolutePathScripts)\ApplyVIPC.ps1" `
+ ("-MinimumSupportedLVVersion 2021 " +
+ "-VIP_LVVersion 2021 " +
+ "-SupportedBitness 64 " +
+ "-RelativePath `"$RelativePath`" " +
+ "-VIPCPath `"Tooling\deployment\Dependencies.vipc`"")
+
+ # 7) Build LV Library (64-bit)
+ Write-Verbose "Building LV library (64-bit)..."
Execute-Script "$($AbsolutePathScripts)\Build_lvlibp.ps1" `
- "-MinimumSupportedLVVersion 2021 -SupportedBitness 64 -RelativePath `"$RelativePath`""
-
- # Rename the file after build
+ ("-MinimumSupportedLVVersion 2021 " +
+ "-SupportedBitness 64 " +
+ "-RelativePath `"$RelativePath`" " +
+ "-Major $Major -Minor $Minor -Patch $Patch -Build $Build " +
+ "-Commit `"$Commit`"")
+
+ # Rename .lvlibp -> lv_icon_x64.lvlibp
+ Write-Verbose "Renaming .lvlibp file to lv_icon_x64.lvlibp..."
Execute-Script "$($AbsolutePathScripts)\Rename-File.ps1" `
"-CurrentFilename `"$RelativePath\resource\plugins\lv_icon.lvlibp`" -NewFilename 'lv_icon_x64.lvlibp'"
- # Build VI Package
- Execute-Script "$($AbsolutePathScripts)\build_vip.ps1" `
- "-SupportedBitness 64 -RelativePath `"$RelativePath`" -VIPBPath `"Tooling\deployment\NI Icon editor.vipb`" -VIP_LVVersion 2021 -MinimumSupportedLVVersion 2021"
+ # -------------------------------------------------------------------------
+ # 8) Construct the JSON for "Company Name" & "Author Name", plus version
+ # -------------------------------------------------------------------------
+ # We include "Package Version" with your script parameters.
+ # The rest of the fields remain empty or default as needed.
+ $jsonObject = @{
+ "Package Version" = @{
+ "major" = $Major
+ "minor" = $Minor
+ "patch" = $Patch
+ "build" = $Build
+ }
+ "Product Name" = ""
+ "Company Name" = $CompanyName
+ "Author Name (Person or Company)" = $AuthorName
+ "Product Homepage (URL)" = ""
+ "Legal Copyright" = ""
+ "License Agreement Name" = ""
+ "Product Description Summary" = ""
+ "Product Description" = ""
+ "Release Notes - Change Log" = ""
+ }
- # Close LabVIEW
+ $DisplayInformationJSON = $jsonObject | ConvertTo-Json -Depth 3
+
+ # 9) Build VI Package (64-bit) — no double-dash parameters
+ Write-Verbose "Building VI Package (64-bit)..."
+ Execute-Script "$($AbsolutePathScripts)\build_vip.ps1" `
+ (
+ # Use single-dash for all recognized parameters
+ "-SupportedBitness 64 " +
+ "-RelativePath `"$RelativePath`" " +
+ "-VIPBPath `"Tooling\deployment\NI Icon editor.vipb`" " +
+ "-MinimumSupportedLVVersion 2021 " +
+ "-LabVIEWMinorRevision $LabVIEWMinorRevision " +
+ "-Major $Major -Minor $Minor -Patch $Patch -Build $Build " +
+ "-Commit `"$Commit`" " +
+ "-ReleaseNotesFile `"$RelativePath\Tooling\deployment\release_notes.md`" " +
+ # Pass our JSON
+ "-DisplayInformationJSON '$DisplayInformationJSON' " +
+ "-Verbose"
+ )
+
+ # 10) Close LabVIEW (64-bit)
+ Write-Verbose "Closing LabVIEW (64-bit)..."
Execute-Script "$($AbsolutePathScripts)\Close_LabVIEW.ps1" `
"-MinimumSupportedLVVersion 2021 -SupportedBitness 64"
-
+
Write-Host "All scripts executed successfully!" -ForegroundColor Green
-} catch {
+ Write-Verbose "Script: Build.ps1 completed without errors."
+}
+catch {
Write-Host "An unexpected error occurred during script execution: $($_.Exception.Message)" -ForegroundColor Red
+ Write-Verbose "Stack Trace: $($_.Exception.StackTrace)"
exit 1
}
diff --git a/pipeline/scripts/Build_lvlibp.ps1 b/pipeline/scripts/Build_lvlibp.ps1
index 9b27cfc0..11fcd778 100644
--- a/pipeline/scripts/Build_lvlibp.ps1
+++ b/pipeline/scripts/Build_lvlibp.ps1
@@ -1,19 +1,34 @@
-#Example: .\Build_lvlibp.ps1 -MinimumSupportedLVVersion "2021" -SupportedBitness "64" -RelativePath "C:\labview-icon-editor"
+#Example: .\Build_lvlibp.ps1 - -MinimumSupportedLVVersion "2021" -SupportedBitness "64" -RelativePath "C:\labview-icon-editor" -Major 1 -Minor 0 -Patch 0 -Build 0 -Commit "Placeholder"
param(
[string]$MinimumSupportedLVVersion,
[string]$SupportedBitness,
- [string]$RelativePath
+ [string]$RelativePath,
+ [Int32]$Major,
+ [Int32]$Minor,
+ [Int32]$Patch,
+ [Int32]$Build,
+ [string]$Commit
)
+Write-Output "PPL Version: $Major.$Minor.$Patch.$Build"
+Write-Output "Commit: $Commit"
+
# Construct the command
$script = @"
-g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness lvbuildspec -- -av -p "$RelativePath\lv_icon_editor.lvproj" -b "Editor Packed Library"
+g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness lvbuildspec -- -v "$Major.$Minor.$Patch.$Build" -p "$RelativePath\lv_icon_editor.lvproj" -b "Editor Packed Library"
"@
-
Write-Output "Executing the following command:"
Write-Output $script
-
+
# Execute the command
Invoke-Expression $script
-Write-Host "Build Editor Packed Library for LabVIEW $MinimumSupportedLVVersion ($SupportedBitness-bit)"
+# Check the exit code
+if ($LASTEXITCODE -ne 0) {
+ g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness QuitLabVIEW
+ Write-Host "Build failed with exit code $LASTEXITCODE."
+ exit 1
+} else {
+ Write-Host "Build succeeded."
+ exit 0
+}
diff --git a/pipeline/scripts/RestoreSetupLVSource.ps1 b/pipeline/scripts/RestoreSetupLVSource.ps1
new file mode 100644
index 00000000..9ccd62a3
--- /dev/null
+++ b/pipeline/scripts/RestoreSetupLVSource.ps1
@@ -0,0 +1,29 @@
+#Example: .\RestoreSetupLVSource.ps1 -MinimumSupportedLVVersion "2021" -SupportedBitness "64" -RelativePath "C:\labview-icon-editor" -LabVIEW_Project "lv_icon_editor" -Build_Spec "Editor Packed Library"
+param(
+ [string]$MinimumSupportedLVVersion,
+ [string]$SupportedBitness,
+ [string]$RelativePath,
+ [string]$LabVIEW_Project,
+ [string]$Build_Spec
+)
+
+# Construct the command
+$script = @"
+g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness -v "$RelativePath\Tooling\RestoreSetupLVSource.vi" -- "$RelativePath\$LabVIEW_Project.lvproj" "$Build_Spec"
+"@
+
+Write-Output "Executing the following command:"
+Write-Output $script
+
+# Execute the command and check for errors
+try {
+ Invoke-Expression $script
+
+ # Check the exit code of the executed command
+ if ($LASTEXITCODE -eq 0) {
+ Write-Host "Unzip vi.lib/LabVIEW Icon API from LabVIEW $MinimumSupportedLVVersion ($SupportedBitness-bit) and remove localhost.library path from ini file"
+ }
+} catch {
+ Write-Host ""
+ exit 0
+}
\ No newline at end of file
diff --git a/pipeline/scripts/RunUnitTests.ps1 b/pipeline/scripts/RunUnitTests.ps1
index c98f842f..9616ad15 100644
--- a/pipeline/scripts/RunUnitTests.ps1
+++ b/pipeline/scripts/RunUnitTests.ps1
@@ -1,30 +1,255 @@
-#Example: .\RunUnitTests.ps1 -MinimumSupportedLVVersion "2021" -SupportedBitness "64" -RelativePath "C:\labview-icon-editor"
+<#
+.SYNOPSIS
+ Run LabVIEW unit tests using g-cli and output a color-coded table of results.
+
+.DESCRIPTION
+ Demonstrates a Setup/MainSequence/Cleanup flow with:
+ - Table-based test results
+ - Color-coded pass/fail
+ - Non-zero exit if g-cli fails or if any test fails
+ - Automatic search for exactly one *.lvproj file by moving up the folder hierarchy
+ until just before the drive root.
+
+.PARAMETER MinimumSupportedLVVersion
+ LabVIEW minimum supported version (e.g., "2021").
+
+.PARAMETER SupportedBitness
+ Bitness for LabVIEW (e.g., "64").
+
+.NOTES
+ PowerShell 7.5+ assumed for cross-platform support.
+ This script *requires* that g-cli and LabVIEW be compatible with the OS.
+#>
+
param(
- [string]$MinimumSupportedLVVersion,
- [string]$SupportedBitness,
- [string]$RelativePath
+ [Parameter(Mandatory=$true)]
+ [string]
+ $MinimumSupportedLVVersion,
+
+ [Parameter(Mandatory=$true)]
+ [ValidateSet("32","64")]
+ [string]
+ $SupportedBitness
)
-# Construct the command
-$script = @"
-g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness -v "$RelativePath\Tooling\Run all tests CLI.vi"
-"@
+# --------------------------------------------------------------------
+# 1) Locate exactly one .lvproj file by searching upward from $PSScriptRoot
+# --------------------------------------------------------------------
+Write-Host "Starting directory for .lvproj search: $PSScriptRoot"
+
+function Get-SingleLvproj {
+ param(
+ [string] $StartFolder
+ )
+
+ $currentDir = $StartFolder
+
+ while ($true) {
+ Write-Host "Searching '$currentDir' for *.lvproj files..."
+ $lvprojFiles = Get-ChildItem -Path $currentDir -Filter '*.lvproj' -File -ErrorAction SilentlyContinue
+
+ if ($lvprojFiles.Count -eq 1) {
+ # Found exactly one .lvproj
+ return $lvprojFiles[0].FullName
+ }
+ elseif ($lvprojFiles.Count -gt 1) {
+ # Found multiple .lvproj files
+ Write-Error "Error: Multiple .lvproj files found in '$currentDir'. Please ensure only one .lvproj is present."
+ $lvprojFiles | ForEach-Object { Write-Host " - $_.FullName" }
+ return $null
+ }
+
+ # If none found, move one level up
+ $parentDir = Split-Path -Path $currentDir -Parent
+
+ # If we've reached or are about to reach the drive root, stop searching
+ $driveRoot = [System.IO.Path]::GetPathRoot($currentDir)
+ if ($parentDir -eq $currentDir -or $parentDir -eq $driveRoot) {
+ Write-Error "Error: Reached the level before root without finding exactly one .lvproj."
+ return $null
+ }
+
+ $currentDir = $parentDir
+ }
+}
+
+$AbsoluteProjectPath = Get-SingleLvproj -StartFolder $PSScriptRoot
+
+if (-not $AbsoluteProjectPath) {
+ # We failed to find exactly one .lvproj in any ancestor up to the level before root
+ exit 3
+}
+Write-Host "Using LabVIEW project file: $AbsoluteProjectPath"
-Write-Output "Executing the following command:"
-Write-Output $script
+# Script-level variables to track exit states
+$Script:OriginalExitCode = 0
+$Script:TestsHadFailures = $false
-# Execute the command and check for errors
-try {
- Invoke-Expression $script
+# Path to UnitTestReport.xml in the same directory as this script
+$ReportPath = Join-Path -Path $PSScriptRoot -ChildPath "UnitTestReport.xml"
- # Check the exit code of the executed command
- if ($LASTEXITCODE -ne 0) {
- Write-Error "Unit tests failed with exit code $LASTEXITCODE."
- exit $LASTEXITCODE
+# -------------------------- SETUP --------------------------
+function Setup {
+ Write-Host "=== Setup ==="
+ if (Test-Path $ReportPath) {
+ try {
+ Remove-Item $ReportPath -Force -ErrorAction Stop
+ Write-Host "Deleted existing UnitTestReport.xml."
+ }
+ catch {
+ Write-Warning "Could not remove UnitTestReport.xml: $($_.Exception.Message)"
+ }
+ }
+ else {
+ Write-Host "No existing UnitTestReport.xml found. Continuing..."
}
-} catch {
- Write-Error "An error occurred while executing the unit tests."
- exit 1
}
-Write-Host "Run unit tests for LabVIEW $MinimumSupportedLVVersion ($SupportedBitness-bit)"
\ No newline at end of file
+# ------------------------ MAIN SEQUENCE ----------------------
+function MainSequence {
+ Write-Host "`n=== MainSequence ==="
+ Write-Host "Running unit tests for LabVIEW $MinimumSupportedLVVersion ($SupportedBitness-bit)"
+ Write-Host "Project Path: $AbsoluteProjectPath"
+ Write-Host "Report will be saved at: $ReportPath"
+
+ Write-Host "`nExecuting g-cli command..."
+ & g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness lunit -- -r "$ReportPath" "$AbsoluteProjectPath"
+
+ $script:OriginalExitCode = $LASTEXITCODE
+ if ($script:OriginalExitCode -ne 0) {
+ Write-Error "g-cli test execution failed (exit code $script:OriginalExitCode)."
+ }
+
+ # If g-cli failed and no report was produced, we can't parse anything
+ if ($script:OriginalExitCode -ne 0 -and -not (Test-Path $ReportPath)) {
+ $script:TestsHadFailures = $true
+ Write-Warning "No test report found, and g-cli returned an error."
+ return
+ }
+
+ # Parse UnitTestReport.xml if it exists
+ if (Test-Path $ReportPath) {
+ try {
+ [xml]$xmlDoc = Get-Content $ReportPath -ErrorAction Stop
+ }
+ catch {
+ Write-Error "UnitTestReport.xml is invalid or malformed: $($_.Exception.Message)"
+ $script:TestsHadFailures = $true
+ return
+ }
+ }
+ else {
+ Write-Error "UnitTestReport.xml not found; cannot parse results."
+ $script:TestsHadFailures = $true
+ return
+ }
+
+ # Retrieve all nodes
+ $testCases = $xmlDoc.SelectNodes("//testcase")
+ if (!$testCases -or $testCases.Count -eq 0) {
+ Write-Error "No entries found in UnitTestReport.xml."
+ $script:TestsHadFailures = $true
+ return
+ }
+
+ # Prepare for tabular output
+ $col1 = "TestCaseName"; $col2 = "ClassName"; $col3 = "Status"; $col4 = "Time(s)"; $col5 = "Assertions"
+ $maxName = $col1.Length
+ $maxClass = $col2.Length
+ $maxStatus = $col3.Length
+ $maxTime = $col4.Length
+ $maxAssert = $col5.Length
+
+ $results = @()
+ foreach ($case in $testCases) {
+ $name = $case.GetAttribute("name")
+ $className = $case.GetAttribute("classname")
+ $status = $case.GetAttribute("status")
+ $time = $case.GetAttribute("time")
+ $assertions = $case.GetAttribute("assertions")
+
+ # If status is empty, treat as "Skipped" so it doesn't cause a false fail
+ if ([string]::IsNullOrWhiteSpace($status)) {
+ $status = "Skipped"
+ }
+
+ # Update max lengths for formatting
+ if ($name.Length -gt $maxName) { $maxName = $name.Length }
+ if ($className.Length -gt $maxClass) { $maxClass = $className.Length }
+ if ($status.Length -gt $maxStatus) { $maxStatus = $status.Length }
+ if ($time.Length -gt $maxTime) { $maxTime = $time.Length }
+ if ($assertions.Length -gt $maxAssert) { $maxAssert = $assertions.Length }
+
+ # Store data
+ $results += [PSCustomObject]@{
+ TestCaseName = $name
+ ClassName = $className
+ Status = $status
+ Time = $time
+ Assertions = $assertions
+ }
+
+ # Mark any test that isn't Passed or Skipped as a failure
+ if ($status -notmatch "^Passed$" -and $status -notmatch "^Skipped$") {
+ $script:TestsHadFailures = $true
+ }
+ }
+
+ # Print table header
+ $header = ($col1.PadRight($maxName) + " " +
+ $col2.PadRight($maxClass) + " " +
+ $col3.PadRight($maxStatus) + " " +
+ $col4.PadRight($maxTime) + " " +
+ $col5.PadRight($maxAssert))
+ Write-Host $header
+
+ # Output test results in color
+ foreach ($res in $results) {
+ $line = ($res.TestCaseName.PadRight($maxName) + " " +
+ $res.ClassName.PadRight($maxClass) + " " +
+ $res.Status.PadRight($maxStatus) + " " +
+ $res.Time.PadRight($maxTime) + " " +
+ $res.Assertions.PadRight($maxAssert))
+
+ if ($res.Status -eq "Passed") {
+ Write-Host $line -ForegroundColor Green
+ }
+ elseif ($res.Status -eq "Skipped") {
+ Write-Host $line -ForegroundColor Yellow
+ }
+ else {
+ Write-Host $line -ForegroundColor Red
+ }
+ }
+}
+
+# -------------------------- CLEANUP --------------------------
+function Cleanup {
+ Write-Host "`n=== Cleanup ==="
+ # If everything passed (and g-cli was OK), delete the report
+ if (($script:OriginalExitCode -eq 0) -and (-not $script:TestsHadFailures)) {
+ try {
+ Remove-Item $ReportPath -Force -ErrorAction Stop
+ Write-Host "`nAll tests passed. Deleted UnitTestReport.xml."
+ }
+ catch {
+ Write-Warning "Failed to delete $($ReportPath): $($_.Exception.Message)"
+ }
+ }
+}
+
+# ------------------- EXECUTION FLOW -------------------
+Setup
+MainSequence
+#Cleanup
+
+# ------------------- FINAL EXIT CODE ------------------
+if ($Script:OriginalExitCode -ne 0) {
+ exit $Script:OriginalExitCode
+}
+elseif ($Script:TestsHadFailures) {
+ exit 2
+}
+else {
+ exit 0
+}
diff --git a/pipeline/scripts/build_vip.ps1 b/pipeline/scripts/build_vip.ps1
index afe2d91f..30c8ac47 100644
--- a/pipeline/scripts/build_vip.ps1
+++ b/pipeline/scripts/build_vip.ps1
@@ -1,55 +1,144 @@
-# Example usage:
-# .\build_vip.ps1 --lv-ver 2021 --arch 64 -SupportedBitness "64" -RelativePath "C:\labview-icon-editor" -VIPBPath "Tooling\deployment\NI Icon editor.vipb" -MinimumSupportedLVVersion 2021
+<#
+This PowerShell script automates the process of updating a LabVIEW VIPB file’s
+“Display Information” fields using the given JSON data and then builds the
+VI Package via g-cli.
+
+Key Steps:
+1. Resolves paths for your VIPB file and LabVIEW project directory.
+2. (Optionally) creates the release notes file if it does not exist.
+3. Calculates the final LabVIEW version string (e.g., "21.0 (64-bit)").
+4. Parses and updates the DisplayInformationJSON ("Package Version" field)
+ with Major, Minor, Patch, Build from script parameters.
+5. Calls a LabVIEW VI (via g-cli) to update the VIPB file’s display information
+ using the updated JSON.
+6. Builds the VI Package (again via g-cli), injecting the same version info
+ (major, minor, patch, build) and release notes.
+7. Handles errors by outputting error details in JSON format.
+
+Example Usage:
+.\build_vip.ps1 `
+ -SupportedBitness "64" `
+ -RelativePath "C:\labview-icon-editor-fork" `
+ -VIPBPath "Tooling\deployment\NI Icon editor.vipb" `
+ -MinimumSupportedLVVersion 2021 `
+ -LabVIEWMinorRevision 3 `
+ -Major 1 `
+ -Minor 0 `
+ -Patch 0 `
+ -Build 2 `
+ -Commit "Placeholder" `
+ -ReleaseNotesFile "C:\labview-icon-editor-fork\Tooling\deployment\release_notes.md" `
+ -DisplayInformationJSON '{"Package Version":{"major":0,"minor":0,"patch":0,"build":0},"Product Name":"","Company Name":"","Author Name (Person or Company)":"","Product Homepage (URL)":"","Legal Copyright":"","License Agreement Name":"","Product Description Summary":"","Product Description":"","Release Notes - Change Log":""}'
+
+#>
+
param (
[string]$SupportedBitness,
[string]$RelativePath,
[string]$VIPBPath,
- [string]$MinimumSupportedLVVersion
+
+ [int]$MinimumSupportedLVVersion,
+
+ [ValidateSet("0","3")]
+ [string]$LabVIEWMinorRevision = "0",
+
+ [int]$Major,
+ [int]$Minor,
+ [int]$Patch,
+ [int]$Build,
+ [string]$Commit,
+ [string]$ReleaseNotesFile,
+
+ [Parameter(Mandatory=$true)]
+ [string]$DisplayInformationJSON
)
-# Resolve paths for consistency
+# 1) Resolve paths
try {
$ResolvedRelativePath = Resolve-Path -Path $RelativePath -ErrorAction Stop
$ResolvedVIPBPath = Join-Path -Path $ResolvedRelativePath -ChildPath $VIPBPath -ErrorAction Stop
-} catch {
- Write-Error "Error resolving paths. Ensure RelativePath and VIPBPath are valid."
+}
+catch {
+ $errorObject = [PSCustomObject]@{
+ error = "Error resolving paths. Ensure RelativePath and VIPBPath are valid."
+ exception = $_.Exception.Message
+ stackTrace = $_.Exception.StackTrace
+ }
+ $errorObject | ConvertTo-Json -Depth 10
exit 1
}
-# Construct VIP_LVVersion_A based on parameters
-switch ("$MinimumSupportedLVVersion-$SupportedBitness") {
- "2021-64" { $VIP_LVVersion_A = "21.0 (64-bit)" }
- "2021-32" { $VIP_LVVersion_A = "21.0" }
- "2022-64" { $VIP_LVVersion_A = "22.3 (64-bit)" }
- "2022-32" { $VIP_LVVersion_A = "22.3" }
- "2023-64" { $VIP_LVVersion_A = "23.3 (64-bit)" }
- "2023-32" { $VIP_LVVersion_A = "23.3" }
- "2024-64" { $VIP_LVVersion_A = "24.3 (64-bit)" }
- "2024-32" { $VIP_LVVersion_A = "24.3" }
- default {
- Write-Error "Unsupported MinimumSupportedLVVersion or SupportedBitness."
- exit 1
- }
+# 2) Create release notes if needed
+if (-not (Test-Path $ReleaseNotesFile)) {
+ Write-Host "Release notes file '$ReleaseNotesFile' does not exist. Creating it..."
+ New-Item -ItemType File -Path $ReleaseNotesFile -Force | Out-Null
}
+# 3) Calculate the LabVIEW version string
+$lvNumericMajor = $MinimumSupportedLVVersion - 2000
+$lvNumericVersion = "$($lvNumericMajor).$LabVIEWMinorRevision"
+if ($SupportedBitness -eq "64") {
+ $VIP_LVVersion_A = "$lvNumericVersion (64-bit)"
+}
+else {
+ $VIP_LVVersion_A = $lvNumericVersion
+}
Write-Output "Building VI Package for LabVIEW $VIP_LVVersion_A..."
-# Construct the script for execution
+# 4) Parse and update the DisplayInformationJSON
+try {
+ $jsonObj = $DisplayInformationJSON | ConvertFrom-Json
+}
+catch {
+ $errorObject = [PSCustomObject]@{
+ error = "Failed to parse DisplayInformationJSON into valid JSON."
+ exception = $_.Exception.Message
+ stackTrace = $_.Exception.StackTrace
+ }
+ $errorObject | ConvertTo-Json -Depth 10
+ exit 1
+}
+
+# If "Package Version" doesn't exist, create it as a subobject
+if (-not $jsonObj.'Package Version') {
+ $jsonObj | Add-Member -MemberType NoteProperty -Name 'Package Version' -Value ([PSCustomObject]@{
+ major = $Major
+ minor = $Minor
+ patch = $Patch
+ build = $Build
+ })
+}
+else {
+ # "Package Version" exists, so just overwrite its fields
+ $jsonObj.'Package Version'.major = $Major
+ $jsonObj.'Package Version'.minor = $Minor
+ $jsonObj.'Package Version'.patch = $Patch
+ $jsonObj.'Package Version'.build = $Build
+}
+
+# Re-convert to a JSON string with a comfortable nesting depth
+$UpdatedDisplayInformationJSON = $jsonObj | ConvertTo-Json -Depth 5
+
+# 5) Construct the command script
$script = @"
-g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness "$ResolvedRelativePath\Tooling\deployment\Modify_VIPB_LabVIEW_Version.vi" -- "$ResolvedVIPBPath" "$VIP_LVVersion_A"
-g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness "$ResolvedRelativePath\Tooling\deployment\BuildVIP.vi" -- "$ResolvedVIPBPath" "$VIP_LVVersion_A"
-g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness QuitLabVIEW
+g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness "$($ResolvedRelativePath)\Tooling\deployment\Modify_VIPB_Display_Information.vi" -- "$ResolvedVIPBPath" "$VIP_LVVersion_A" '$UpdatedDisplayInformationJSON'
+g-cli --lv-ver $MinimumSupportedLVVersion --arch $SupportedBitness vipb -- --buildspec "$ResolvedVIPBPath" -v "$Major.$Minor.$Patch.$Build" --release-notes "$ReleaseNotesFile" --timeout 300
"@
-# Output the script for debugging
Write-Output "Executing the following commands:"
Write-Output $script
-# Execute the script and handle potential errors
+# 6) Execute the commands
try {
Invoke-Expression $script
Write-Host "Successfully built VI package: $ResolvedVIPBPath"
-} catch {
- Write-Error "An error occurred while executing the build commands."
+}
+catch {
+ $errorObject = [PSCustomObject]@{
+ error = "An error occurred while executing the build commands."
+ exception = $_.Exception.Message
+ stackTrace = $_.Exception.StackTrace
+ }
+ $errorObject | ConvertTo-Json -Depth 10
exit 1
}
diff --git a/pipeline/scripts/unit_tests.ps1 b/pipeline/scripts/unit_tests.ps1
new file mode 100644
index 00000000..3ae6a511
--- /dev/null
+++ b/pipeline/scripts/unit_tests.ps1
@@ -0,0 +1,82 @@
+# .\unit_tests.ps1 -RelativePath "C:\labview-icon-editor" -AbsolutePathScripts "C:\labview-icon-editor\pipeline\scripts"
+param(
+ [Parameter(Mandatory = $true)]
+ [string]$RelativePath,
+
+ [Parameter(Mandatory = $true)]
+ [string]$AbsolutePathScripts
+)
+
+# Helper function to check for file or directory existence
+function Assert-PathExists {
+ param(
+ [string]$Path,
+ [string]$Description
+ )
+ if (-Not (Test-Path -Path $Path)) {
+ Write-Host "The $Description does not exist: $Path" -ForegroundColor Red
+ exit 1
+ }
+}
+
+# Helper function to execute scripts sequentially
+function Execute-Script {
+ param(
+ [string]$ScriptPath,
+ [string]$Arguments
+ )
+ Write-Host "Executing: $ScriptPath $Arguments" -ForegroundColor Cyan
+ try {
+ # Build and execute the command
+ $command = "& `"$ScriptPath`" $Arguments"
+ Invoke-Expression $command
+
+ # Check for errors in the script execution
+ if ($LASTEXITCODE -ne 0) {
+ Write-Host "Error occurred while executing: $ScriptPath with arguments: $Arguments. Exit code: $LASTEXITCODE" -ForegroundColor Red
+ exit $LASTEXITCODE
+ }
+ } catch {
+ Write-Host "Error occurred while executing: $ScriptPath with arguments: $Arguments. Exiting." -ForegroundColor Red
+ exit 1
+ }
+}
+
+# Main script logic
+try {
+ # Validate required paths
+ Assert-PathExists $RelativePath "RelativePath"
+ Assert-PathExists "$RelativePath\resource\plugins" "Plugins folder"
+ Assert-PathExists $AbsolutePathScripts "Scripts folder"
+
+ # Clean up .lvlibp files in the plugins folder
+ Write-Host "Cleaning up old .lvlibp files in plugins folder..." -ForegroundColor Yellow
+ $PluginFiles = Get-ChildItem -Path "$RelativePath\resource\plugins" -Filter '*.lvlibp' -ErrorAction SilentlyContinue
+ if ($PluginFiles) {
+ $PluginFiles | Remove-Item -Force
+ Write-Host "Deleted .lvlibp files from plugins folder." -ForegroundColor Green
+ } else {
+ Write-Host "No .lvlibp files found to delete." -ForegroundColor Cyan
+ }
+
+ # Run Unit Tests
+ Execute-Script "$($AbsolutePathScripts)\RunUnitTests.ps1" `
+ "-MinimumSupportedLVVersion 2021 -SupportedBitness 32 -RelativePath `"$RelativePath`""
+
+ # Close LabVIEW
+ Execute-Script "$($AbsolutePathScripts)\Close_LabVIEW.ps1" `
+ "-MinimumSupportedLVVersion 2021 -SupportedBitness 32"
+
+ # Run Unit Tests
+ Execute-Script "$($AbsolutePathScripts)\RunUnitTests.ps1" `
+ "-MinimumSupportedLVVersion 2021 -SupportedBitness 64 -RelativePath `"$RelativePath`""
+
+ # Close LabVIEW
+ Execute-Script "$($AbsolutePathScripts)\Close_LabVIEW.ps1" `
+ "-MinimumSupportedLVVersion 2021 -SupportedBitness 64"
+
+ Write-Host "All scripts executed successfully!" -ForegroundColor Green
+} catch {
+ Write-Host "An unexpected error occurred during script execution: $($_.Exception.Message)" -ForegroundColor Red
+ exit 1
+}
diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 00000000..fb2434bd
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,2 @@
+requests==2.28.2
+mysql-connector-python==8.0.32
\ No newline at end of file
diff --git a/resource/plugins/NIIconEditor/Class/Settings/GET/GET_Show.vi b/resource/plugins/NIIconEditor/Class/Settings/GET/GET_Show.vi
index f78b3a46..3db86f56 100644
Binary files a/resource/plugins/NIIconEditor/Class/Settings/GET/GET_Show.vi and b/resource/plugins/NIIconEditor/Class/Settings/GET/GET_Show.vi differ
diff --git a/resource/plugins/NIIconEditor/Class/Settings/Initialization/Settings Initialization.vi b/resource/plugins/NIIconEditor/Class/Settings/Initialization/Settings Initialization.vi
index 526cf8ed..bcd76ecd 100644
Binary files a/resource/plugins/NIIconEditor/Class/Settings/Initialization/Settings Initialization.vi and b/resource/plugins/NIIconEditor/Class/Settings/Initialization/Settings Initialization.vi differ
diff --git a/resource/plugins/NIIconEditor/Class/Settings/SET/SET_Show.vi b/resource/plugins/NIIconEditor/Class/Settings/SET/SET_Show.vi
index 300b3995..e4616a23 100644
Binary files a/resource/plugins/NIIconEditor/Class/Settings/SET/SET_Show.vi and b/resource/plugins/NIIconEditor/Class/Settings/SET/SET_Show.vi differ
diff --git a/resource/plugins/NIIconEditor/Class/Settings/Settings.lvclass b/resource/plugins/NIIconEditor/Class/Settings/Settings.lvclass
index 0bf51fe0..7e4e3404 100644
--- a/resource/plugins/NIIconEditor/Class/Settings/Settings.lvclass
+++ b/resource/plugins/NIIconEditor/Class/Settings/Settings.lvclass
@@ -3,15 +3,16 @@
true
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!)<!!!*Q(C=\>4.51*"%-8RB_8"+RF9J.!:7+2!#JU#6Y_E]&)A"6,I&%C"&.<`$KWF61A?N-I$MQ\#G[]@M].+ITR*DZJOF:?LZ80\X0G^8GC@PLZ='N_@PWG@'[[-H]\DJSPD,`FP&6UN^`:\_`^OPXW]8W``#0[W3)MBJ2<6V+4'_(:4E2>ZE2>ZE2?ZS5VO=J/<X/2*HO2*HO2*HO2"(O2"(O2"(O4D)B?ZS%8/LB3,&QM6ER94&*WBK(AJ0)7H]"1?0KLQ&*\#5XA+$VV5?!J0Y3E]B9>B+DS&J`!5HM,$6%.3YS,(5XC98M:D0-:D0-<$ED)?!T#,G9H.*$"E'MU<YT%?Y_'ND->YD->YD)>G'9`R')`R'!^$RKZY;/;,(!`4+0%EHM34?")05SPR**\%EXA3$]MJ]33?"*%MG%Q/1=GAJ%0S)@%E(PYJ]33?R*.Y%A^.YQ\FW*F:-V`E?!*0Y!E]A3@Q-)5#4_!*0)%H]$#N!E`A#4S"*`#QF!*0Y!E]!329F/564"9-$$I&1?$B<ZS7'(@*1R,D[J`G_;#K$[$[9+E0D0IAK'_Q_M;J<YB[I^5<K.Y9^2>7@R%V5,WQ?E*V2ZVY06)0V$VV2^V3.^1V>56>TE.`O?0J>.,R?.4B=."_P^>ON^.WO^6GM^&[P>:KN>*SO@RY7DVTH=PCJ]_F6`L_24U`F`\$MV%0GDY^ZNGD.]<;?U!!!!!!
- 1.0.0.14
+ 553680896
+ 1.0.0.15
true
true
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!6,0%.M>8.U:8)_$1I]4G&N:4Z1:7Y],UZB<75_$1I]4H6N27RU=TYY0#^/>7V&<(2T0AU+0&5T-DY.#DR/97VF0E:P=G6H=G^V<G1A1W^M<X)],UZB<75_$1I]6G&M0D%R-41R-T5Z0#^797Q_$1I],V5T-DY.#DR6-T)_$1I]4G&N:4Z#97.L:X*P>7ZE)%.P<'^S0#^/97VF0AU+0&:B<$YR.D=X.T)R.4QP6G&M0AU+0#^6-T)_$1I]1WRV=X2F=DY.#DR/97VF0E:J<'QA5'&U>'6S<DQP4G&N:4Y.#DR/>7V&<(2T0DA],UZV<56M>(-_$1I]64A_$1I]4G&N:4Z3<X=A-$QP4G&N:4Y.#DR797Q_-4EV0#^797Q_$1I],V5Y0AU+0&5Y0AU+0%ZB<75_5G^X)$%],UZB<75_$1I]6G&M0D%Z.4QP6G&M0AU+0#^6/$Y.#DR6/$Y.#DR/97VF0F*P>S!S0#^/97VF0AU+0&:B<$YR/45],V:B<$Y.#DQP64A_$1I]64A_$1I]4G&N:4Z3<X=A-TQP4G&N:4Y.#DR797Q_-4EV0#^797Q_$1I],V5Y0AU+0&5Y0AU+0%ZB<75_5G^X)$1],UZB<75_$1I]6G&M0D%Z.4QP6G&M0AU+0#^6/$Y.#DR6/$Y.#DR/97VF0F*P>S!V0#^/97VF0AU+0&:B<$YR/45],V:B<$Y.#DQP64A_$1I]64A_$1I]4G&N:4Z3<X=A.DQP4G&N:4Y.#DR797Q_-4EV0#^797Q_$1I],V5Y0AU+0&5Y0AU+0%ZB<75_5G^X)$=],UZB<75_$1I]6G&M0D%Z.4QP6G&M0AU+0#^6/$Y.#DQP1WRV=X2F=DY.#DR*-49_$1I]4G&N:4Z8;72U;$QP4G&N:4Y.#DR797Q_-4QP6G&M0AU+0#^*-49_$1I]26=_$1I]4G&N:4Z.<W2F0#^/97VF0AU+0%.I<WFD:4Z$<X"Z0#^$;'^J9W5_$1I]1WBP;7.F0E^S0#^$;'^J9W5_$1I]1WBP;7.F0E6Y9WRV=WFW:3"0=DQP1WBP;7.F0AU+0%.I<WFD:4Z#;81A1WRF98)],U.I<WFD:4Y.#DR$;'^J9W5_4G^U)%.P=(E],U.I<WFD:4Y.#DR$;'^J9W5_4G^U)%^S0#^$;'^J9W5_$1I]1WBP;7.F0EZP=C"&?'.M>8.J>G5A4X)],U.I<WFD:4Y.#DR$;'^J9W5_4G^U)%*J>#"$<'6B=DQP1WBP;7.F0AU+0&:B<$YQ0#^797Q_$1I],U680AU+0%6-0AU+0%ZB<75_5X2Z<'5],UZB<75_$1I]1WBP;7.F0F.P<'FE0#^$;'^J9W5_$1I]1WBP;7.F0E2B=WA],U.I<WFD:4Y.#DR$;'^J9W5_2'^U0#^$;'^J9W5_$1I]1WBP;7.F0E2B=WAA2'^U0#^$;'^J9W5_$1I]1WBP;7.F0E2B=WAA2'^U)%2P>$QP1WBP;7.F0AU+0&:B<$YQ0#^797Q_$1I],U6-0AU+0%6-0AU+0%ZB<75_2GFM<#"3>7RF0#^/97VF0AU+0%.I<WFD:4Z&>G6O)%^E:$QP1WBP;7.F0AU+0%.I<WFD:4Z8;7ZE;7ZH0#^$;'^J9W5_$1I]6G&M0D!],V:B<$Y.#DQP25Q_$1I]25Q_$1I]4G&N:4Z&<G1A1W&Q=TQP4G&N:4Y.#DR$;'^J9W5_2'6G986M>$QP1WBP;7.F0AU+0%.I<WFD:4Z'<'&U0#^$;'^J9W5_$1I]6G&M0D!],V:B<$Y.#DQP25Q_$1I],U.M>8.U:8)_$1I!!!!!
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!6,0%.M>8.U:8)_$1I]4G&N:4Z1:7Y],UZB<75_$1I]4H6N27RU=TYY0#^/>7V&<(2T0AU+0&5T-DY.#DR/97VF0E:P=G6H=G^V<G1A1W^M<X)],UZB<75_$1I]6G&M0D%R-41R-T5Z0#^797Q_$1I],V5T-DY.#DR6-T)_$1I]4G&N:4Z#97.L:X*P>7ZE)%.P<'^S0#^/97VF0AU+0&:B<$YR.D=X.T)R.4QP6G&M0AU+0#^6-T)_$1I]1WRV=X2F=DY.#DR/97VF0E:J<'QA5'&U>'6S<DQP4G&N:4Y.#DR/>7V&<(2T0DA],UZV<56M>(-_$1I]64A_$1I]4G&N:4Z3<X=A-$QP4G&N:4Y.#DR797Q_-4)W0#^797Q_$1I],V5Y0AU+0&5Y0AU+0%ZB<75_5G^X)$%],UZB<75_$1I]6G&M0D%S.DQP6G&M0AU+0#^6/$Y.#DR6/$Y.#DR/97VF0F*P>S!S0#^/97VF0AU+0&:B<$YR-D9],V:B<$Y.#DQP64A_$1I]64A_$1I]4G&N:4Z3<X=A-TQP4G&N:4Y.#DR797Q_-4)W0#^797Q_$1I],V5Y0AU+0&5Y0AU+0%ZB<75_5G^X)$1],UZB<75_$1I]6G&M0D%S.DQP6G&M0AU+0#^6/$Y.#DR6/$Y.#DR/97VF0F*P>S!V0#^/97VF0AU+0&:B<$YR-D9],V:B<$Y.#DQP64A_$1I]64A_$1I]4G&N:4Z3<X=A.DQP4G&N:4Y.#DR797Q_-4)W0#^797Q_$1I],V5Y0AU+0&5Y0AU+0%ZB<75_5G^X)$=],UZB<75_$1I]6G&M0D%S.DQP6G&M0AU+0#^6/$Y.#DQP1WRV=X2F=DY.#DR*-49_$1I]4G&N:4Z8;72U;$QP4G&N:4Y.#DR797Q_-TQP6G&M0AU+0#^*-49_$1I]26=_$1I]4G&N:4Z.<W2F0#^/97VF0AU+0%.I<WFD:4Z$<X"Z0#^$;'^J9W5_$1I]1WBP;7.F0E^S0#^$;'^J9W5_$1I]1WBP;7.F0E6Y9WRV=WFW:3"0=DQP1WBP;7.F0AU+0%.I<WFD:4Z#;81A1WRF98)],U.I<WFD:4Y.#DR$;'^J9W5_4G^U)%.P=(E],U.I<WFD:4Y.#DR$;'^J9W5_4G^U)%^S0#^$;'^J9W5_$1I]1WBP;7.F0EZP=C"&?'.M>8.J>G5A4X)],U.I<WFD:4Y.#DR$;'^J9W5_4G^U)%*J>#"$<'6B=DQP1WBP;7.F0AU+0&:B<$YQ0#^797Q_$1I],U680AU+0%6-0AU+0%ZB<75_5X2Z<'5],UZB<75_$1I]1WBP;7.F0F.P<'FE0#^$;'^J9W5_$1I]1WBP;7.F0E2B=WA],U.I<WFD:4Y.#DR$;'^J9W5_2'^U0#^$;'^J9W5_$1I]1WBP;7.F0E2B=WAA2'^U0#^$;'^J9W5_$1I]1WBP;7.F0E2B=WAA2'^U)%2P>$QP1WBP;7.F0AU+0&:B<$YQ0#^797Q_$1I],U6-0AU+0%6-0AU+0%ZB<75_2GFM<#"3>7RF0#^/97VF0AU+0%.I<WFD:4Z&>G6O)%^E:$QP1WBP;7.F0AU+0%.I<WFD:4Z8;7ZE;7ZH0#^$;'^J9W5_$1I]6G&M0D!],V:B<$Y.#DQP25Q_$1I]25Q_$1I]4G&N:4Z&<G1A1W&Q=TQP4G&N:4Y.#DR$;'^J9W5_2'6G986M>$QP1WBP;7.F0AU+0%.I<WFD:4Z'<'&U0#^$;'^J9W5_$1I]6G&M0D!],V:B<$Y.#DQP25Q_$1I],U.M>8.U:8)_$1I!!!!!
- )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!#7R5F.31QU+!!.-6E.$4%*76Q!!)6Q!!!26!!!!)!!!)4Q!!!!6!!!!!2"4:82U;7ZH=SZM>G.M98.T!!!!!!!!I#%!A!!!-!!!+!!%1!!!!!1!!Q!]!,Q!(U#!)A!!!!!"!!%!"P````]!!!!!!!!!!!!!!!"?$(72Z6R91;B+"DGW3W@F!!!!$!!!!"!!!!!#GZ^-J^Q/KU[A&D/A<%,<C>1>D.G0!,)%[9!*G/TY1HY!!!!!!!!!!/0<DP<MK@B-E&IH88%/^%I"!!!!`````^1>D.G0!,)%[9!*G/TY1HY!!!!17^?ED=ZMB,HAF!A>S1]Z!A!!!!1!!!!!!!!"6A!"4&:$1Q!!!!1!!F:*4%)!!!!!5&2)-!!!!!5!!1!"!!!!!!)!!F:*1U-!!!!!!1B'<WZU,G.U<!"16%AQ!!!!.Q!!!!5(0(:J<'FC0B"-97*73568)%FD<WYA16"*"WRW8WFD<WY)1W^O>(*P<(-)2G^O>#ZD>'Q!!!!!!!&#!!!!!!!#6EF$1Q!!!!!!!1V"<'FH<GVF<H1O9X2M5&2)-!!!!$Q!!!!&"TRW;7RJ9DY14'&C6EF&6S"*9W^O)%&131>M>F^J9W^O#%.P<H2S<WRT$5&M;7>O<76O>#ZD>'Q!!!!!!!*#!!!!!!!#6EF$1Q!!!!!"$5:P<H1A5WF[:3ZD>'R16%AQ!!!!/Q!!!!5+0(*F=W^V=G.F0A>Q<(6H;7ZT$%Z*37.P<E6E;82P=AB$<WZU=G^M=QV'<WZU)&.J?G5O9X2M!!!!!!!$1A!!!!!!!Q!!!!!!!A!%!!!!!!!D!!!!'HC=9W"H9'VAO-!!R)Q/4!V-#5$7"Q9'DA!'!%J4":I!!!!!3A!!!3>YH'.AQ!4`A1")-4)QM#1!;29U=4!.9V-4Y$)8FVV1=7;I'VG2Z:A2KI#=&U#;#31+V7)!E7)R10)>(0"$[1N)9A$D]S?,!!!!!!!-!!&73524!!!!!!!$!!!!%Q!!!!FYH'.A9'"E:!!#!!!5!!-!!!!!$#%!A!!!!!1S-3YQ!!!!!!QB!)!!!!!%-D%O-!!!!!!-)1#!!!!!"$)R,D!!!!!!$#%!A!!!!!1S-3YQ!!!!!!QB!)!!!!!%-D%O-!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!)$`````A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!9!!"A:A!!99'!!'9!9!"I!"!!<!!Q!'M!U!"IQ\!!;$V1!'A+M!"I$6!!;!KQ!'A.5!"I#L!!;!V1!'9+Y!"BD9!!9'Y!!'!9!!"`````Q!!"!$```````````````````````````````````````````]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!#ZO1!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!#ZU=8,U<E!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!#ZU=7`P\_`S^'Z!!!!!!!!!!!!!!!!!!!!!0``!!#ZU=7`P\_`P\_`P]P2O1!!!!!!!!!!!!!!!!!!``]!S]7`P\_`P\_`P\_`P\`,U1!!!!!!!!!!!!!!!!$``Q$&R<_`P\_`P\_`P\_`P``,!!!!!!!!!!!!!!!!!0``!-8,S]7`P\_`P\_`P````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P&P\_`P```````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,R>(````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P,`````````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]P`````````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,S``````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P,`````````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]P`````````R1!!!!!!!!!!!!!!!!$``Q$,S]P,S]P,S````````]P,!!!!!!!!!!!!!!!!!0``!!$&R=P,S]P,`````]P2R1!!!!!!!!!!!!!!!!!!``]!!!!!R=P,S]P``]P,R1!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!-8,S]P,PQ!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!$&PQ!!!!!!!!!!!!!!!!!!!!!!!!!!````````````````````````````````````````````!!!!!A!%!!!!!!&X!!&'5%B1!!!!!Q!#6%2$1Q!!!!%)2G^O>#ZD>'Q!5&2)-!!!!$=!!!!&"TRW;7RJ9DY14'&C6EF&6S"*9W^O)%&131>M>F^J9W^O#%.P<H2S<WRT#%:P<H1O9X2M!!!!!!!!1A!!!!!!!!!"!!!!L6"53$!!!!!!!!!!!!!#6%2$1Q!!!!!!!1V'<WZU)&.J?G5O9X2M5&2)-!!!!$M!!!!&#DRS:8.P>8*D:4Y(='RV:WFO=QR/35FD<WZ&:'FU<X))1W^O>(*P<(-.2G^O>#"4;8JF,G.U<!!!!!!!!%)!!!!!!!!!!1!!!.:16%AQ!!!!!!!!!!!!!F2%1U-!!!!!!!%.17RJ:WZN:7ZU,G.U<&"53$!!!!!]!!!!"1=]>GFM;7)_%%RB9F:*26=A37.P<C""5%E(<(:@;7.P<AB$<WZU=G^M=QV"<'FH<GVF<H1O9X2M!!!!!!!!1A!!!!!!!!!"!!!![6"53$!!!!!!!!!!!!!$!!!!!"!!!!!$!!!!!!!!!!!!!!!!!!!/DA!!+_RYH-6;$8"5V27_<\-*OZO%\#\Z7R8T3._ON!,F2QPS)U)W2#!`S'\%-I\SEHV*XL#\,\Z^'QS>11@8++X+N&4M5,#UN<1TFEK,6L#UIFV2OWWVVFK6TE3=K6/'`KF9(=JG?_[^\X>`%N)"47<?XHPO0?@=?]^XTLHXX9@1V8^T.^L'U,9M9NQ@1;%^CVS2$).1?L9$K8_"%?4O:P[,G&I@EU5X/,L>*WVDT"6:6"8*""RTATP1P[&X<H`O+O9S>*`\&(3N=0N!G#O,;C+:"G9.._LGHLC#WV'O3@7A[?Y(G4(<,6T4RYY(5R)I2+G:_/G:T9QB*DD$<E]VL_0D1IL$6/>MBY_)>';2/ZCJFLH2KU!CK([?C'3['*(:J)F%)()G/HTYM-(EI5Q"-IR&Q-/)Q,76[2K(RQM]#7ZU&O&R%2\1MV84%WQ;WY8(DJHS7;>R'?!%NDP6'7.7D3V\!W(,Z8,!"E_6<3#,;LH2F1[@YV4E\@,KGV*0)Q9R[>M>O1/ZAZD@UYG.10J[Q1Z"-*.`-?-/14W526^):7S<E"V<9ATU.;$DR"*WT2*,M367%5MYATP=S$$&LAF-%<3HG[?X2*-*2:":K9`ND@+*"$MICU/])L!28O%,D<1MG(%OR#O!F2&]I$JE:_L1-@/#3_D!A1/Q#0!U7+](VA:O6/@TQ'R]-"NNU30'IG/NROINB^5,@B,ORSPI8WT49&N/9,O#0"?1ZS\SX%[?/QQYTQ=Y?^TZQ\8!_>K,$_=P!=KWZ=%:(9&?,Y]$T975S12HD$%0/D)/TS,AO=M#:[T(I_E:$]\8&=!:;;JU//`?P>P#"A::L-0:TD!5TKF8=_>TZT'I-\G4T'TU"Q,K=M,2">;):/S)R5L?!3XP)^'+Y3.Y_>P)]N=:'*Y+[S^K%T^<>0V:'[)YLAE.3&P9M#$(R$A@43SH^H$\K7>"8]4.:&+@"W)6D.SP'[I[CYZ'-B8//$>;<V*?BGJ1,<L?AOHC$F42N7L6&\M[3_N<2P7FZUR2O[K;+\0I'@#);\D2/KT24O"743/(JYG#5\8@GZB&,@`:6(\$60[45=['4/8V$J_TS4$>,]"U`C]D`U95`+2K+@7I-P#IE>N1.;J7_Y("NOM'?Q5'^AY;M"JM@UG$$5T+9/X]--3?-.]T'9.^\T-TW0=`@9->+')Q?\\")%XMCG2IFE!<97#PA"N<$0:QS3TB'T`#M28%9+HGM(#H5BDF>B@GAQ:9GDP1ER0GAU@S]M%U%*UUQA`."]:YD#8::FI3,3O5;VGBD%4`A_2ZGDT@-$,"NSW:1"OI*20MOTC:)!^9&AD$X"]NFBQ/A?G?'S@1@S=`/2"4<U;(RO&Z,$]Z!-]BY(FOYO4QA`TEA&GNS;'9>8[I7[=Q2:Q&B%++?#$X6V3&8C%JQE<Y@JR&LQ=TD5C&:O[:X.H=OWA0-1XN%1&$=BG7$G5<!CR:!@[G#P$VQ3?;VFA2XD$B0CD6("+X&L>=E2!%WN\35(,JN;X,-L!@LU!I/.KU"KPR!NN-.*.-@YI[)-;$"^1/UT@]/`>0"+(*'%`RA0R`T*[J6:7Z#Z1Z*V4'.;-,V@2/FKG$'$'@'X7:QIM.`GOV717<=BZ6EYNI=BFZ*D5$X7V([=]2Q]$9K&\8/(J4CH`/X$Y^X$0V..T<C0<''[DW"F3*!E2D&>&94W*`G2[`PW'+Z1_:SBWGO![S'[DM-C+\^GYMOR*EVYYL__MG?1_;SOUGW=YMURD-/-S2&@`6!W)UF`_D>=FUXW6]8)9R">@O"\!,OT>#YX.:JNL4C,UR\:O/Y9)0$-K!Q#K1&FAR4MJCLR3@E`,B:G?D9[.`=56AR":A57"',N"M#B&PGX25L[5"@!I%](NL4SV:5P\?4L5HO0RJX?52OAJNM\L]G>)OPW3#J+<N1JQLIG*`0#<%F5EY`^^,/`_FUQP,^I_]:30U$6FG,N[LG=+$3V]K,;MRS`'1/UFYO%,XW.R`9/?3GW#`2N)`.QGP"7U,67XO3[].9M1CG,ZT$1E3GD:5DI9!]3/F%%`6E1$"4CYK6'?:[WB-KK+Z7Y^*UR"@)C9BETJOQIGFZXDN5;&0K?A&>!BSO3TW$SB'X&C=SL"W:TUE:L.XVS&&6>6%-[9[\T/G),(#OL&]X)3GSL05#2VG@`7=!6()?99W/9F`HAD.?R<\J_/5Y;-(K9`G\E?/X%`19V9@@;+YDZ;"LVRZ)<\#J:J83:0STE0&P@.3;936`'ERPXQKCZYU:_Q!WEN7RK'.]ZDBEK9E7A;*KGL#H79J"]F@CV];DHBJ>-#:;!_YQW*ON);K=.$$G"W/9S\96L\V^F^A7ZE=W5^Q;>?Q_0&,"CY`@N&50G%KPW"*G/B8.'&W54X(K>N^&>:W$_AZ>OQ9[)'H65^WQ)4`@F.ZK;G]R+4HY3R[.J*BH8/ZU5L,HK--`0P_C@9=>G4S]@&##H@=;?STH]]\"_'`7E#,&LN?+ZKNX]OC8U=ST5Q6A#RI'CKWW#-KVODO],5M?A&[?G$R)J<8>D<U4<3$>'3UM<Q)9^G3&VPO1P=64,S/D+7/<!]?J6B\#6C8QL*BD0UL^V\O@/[=^1CI(T&-Y2!ABCG!JU?."8E:TCR$Z($EV!Z(>7A($(;0'<2E@W1Q`59`($H6Q^%^[A2,]W3!:QMZ($H6Q^%^:DXD(9Z_#\0NTDO]\D9:\@7CD,"-P]-O76(M)/[=S#5HER=B,0X?P*/<4;/Y+T"3VML/=>^<"BT45F>D)XK/;CGD<)@`:W0_QW0_*RH`5YC-Q5P'Y0'X,0$`X.V["$XL@RJ2X]'>=^#:>+OA3_M`!K.Q(P6]1$,("ZY0S?_(HL01`7O!!YZ&TL0=!=;^8>M&<0>7Y5GY3>I+_N"/TM=YGNQM6(?G@?5L:*'0JHW6Z*>>'?6\.[>^,L5G23.JH]?IM+M60CLWJHV6F*:8\?2F7>KC=^#K+K7RA+:T4\-U;61XJ8<(9=]<%>C/%+B:+5G<W26R2<QDS9-;=V645U!TV&C;.#I2%O0D<">U$3H$53(NKS_AK>+H&W`1B457NGN.8NS5'"#C@7RI/.9D2>G&--?6-B_*#M0MD8Q=J)2<ULYJ,>#`2R:BNGJ*V4X.8.8&4N7I'K'_B9^"H7=$L&<KY*5")IZ7>8&'V3S/5D5#$#=?Y77?]*/3Q7^5T@S5;P$$(CMJ$_-G7G,<*'7!W-.+5/6?6I3K3[P,;^4IV3V3$+IB0JYA10&;[KJE2YM54UB20E([U[,;6'OJ[W*L>,*'=7'+QA/'?,7:6F1Z^8E5!W7G"IV7U3,*01,W06J1:8B..@-%#6&XDB9J+9O#T-[</WP?`&HTLC63++F4W',K!$66=%-_S=#GO55@=GN#E@FYPR#6W.;)E%D!D/N8!76T&![DKA%[B)C9D)&D&']QRLN+&I1%=9B1LSQ/+J15\RV1[WR('#T5"N#*38%9<,676!>@I^>V:,8R3970C<AE3()`NEC67N)Q;KY;'.7I_O$;IF)0B*I/+3YF"PF?C!!?F511&"*EM1],6WGU7K>7OR/Q=+PR1;+0M&;MDI%-G+"T46,M&63P8MP,CLA:BFCZ6B94CB#H^0*W]%WA4GV0^II2HK7!!SE_F9!$QR::6-2YPR()V$9S/$5_!D1"[&V**1JB"GQ.F@6#HY#87,$-IN\;-CDU1J26Q$_PB!;D)\NIFAKN;W<.7T2L`D5Q*.SB2*OD)]SWXKHA/&(2!;$"+;7W1_S6J945JVA'-+6$R-#+YJYQ=$E/"M!LLQQ0#D"`/3%/]<D8%,;;G0*VCH'I/`'0FJ$7]6%?6E2CWU8+"^-KI'EBOXC$%<),WX7%L?-(B_5ER!P(/GQU-J$S^4Q`*/*@#1)^4%,$=UV)[*@Q$/)2):Y1=&4*IWBRC*+\6Q0+N;)7BSRV)Q\J:$VWB!<EJ!,$K!T&_'C5R?=J'/?5U(#UDR@)M%C3!33IW;<1:B6B@A$G!$*I1@/UM"!<4#;IT1B);]*C4%C1Y+"/OD;0IL*?8IRM:+<]6HXX%*;&HG4PA+#1Y/UR6\7U8E!TP-(3J&(,QUF!);T)T9)=Y<(BKN33&BP-63-W;&2^I7_72=BI9,5.I@$N,6O&8L89'O_0KE5=S.2CGS$(V#+7I":$A\T7)<1&)]/R1?C*A%O$S:Q<Y$>)SZ7Y4/DM@%NNA9.V617KRQ*4R\QV>+?XFW0XOGK]<KA^20>^,L@8AX?$,I`83X[^RE\VO_;>[D\4/U@UF0</M7<&%#^'_2Y)U8U54?5%6@1^9W6AR.:['^M7;-RZ@53[D_ZXKQ)D#,_P=(;;TC+/ES?3_E=QRAX;!PV$#TAYY-O/P&=:;UN?I7W_I#OU>0/U"8+%(929/]RC').H#YH#+\8WYF>K9<2`QCOVDC*8;L@!0#<]R++TS*6;N8;F:C08;,?3:]3Y4,OJY$).$^&SG2;[_*^6B)P>H/V&S^$"=7\"OANOTJ9"6[>W8CP+=X0"T>ESU./J[2HP=,CBY/:MG8%U,0V:R3XDX*SJ(V?]GTO*&K#DJJOTG]!G_-B^/H=?4MG<L/P@6R+S<2=)W=J6%)$QXIO0Z2OD-IN_60DOJR&QQ&XM>T]\K:YBU\O@/N!TE_A"$2>&$[R80XWV7ZHH?D02*OM<%(4OX$H1#5`4OQR\CM-5-VA(CPDD,"3:W"^&MT__Y0_+D<LE6$C_'^^IX+J^IZ&\%`"R'HX,'K^O+`G.RNY,?1M0RL]MJ%CSQ";*7J0Z8/0WT_RTD5W@`O=;@*(0.7J-HWN-G)D!LCNUO\Y0>"N[X'L8NJ*W@@Q#P\WZP%/1_Q5WC=]'5@Q&4I+6YGSP&)O*_:^YA0VO`-TMN`L4N^_;)P:T8ZD^1FQQ>W*D$4,^F7'TFG:RNY,3O\+I,NDC0?Z?D>@'M>L2[NY(#2:S<<VDH_/D^"P[&\DJ>JUT^3LTA'U'N[@*U@A`;OW"EQ!!!!!!"!!!!+-!!!!%!!!!!!!!!!Q!!5*%3&!!!!!!!!-!!!!%!!!!!!!!!'5!!!"V?*RD9'!I&*"A_M>1^Z?"3?!LE#(^FY&:U)`R.Q-$JZ`!93$.+#!*&*<^S]!OK!U7VD[CS]%!";JMD"S3()=&/=!S(#U;$0```V=J9O4Y?O1;8.%2(TB4::9]BQ1!:1A:GA!!!!!!!!1!!!!(!!!&\Q!!!!A!!!!B8WZJ8URB=X2,<G^X<E^X<GFO:UR71WRB=X.$<(6T>'6S!!!"7S%!A!!!!!!"!!A!-0````]!!1!!!!!"0Q!!!!M!)%!B'UVF=G>F)(6T:8)A<'&Z:8*T)'^O)'.P<7VJ>!!A1#%;5X2P=G5A-X*E)("B=H2Z)&2F<8"M982F=T]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!)Q$R!!!!!!!!!!%)2G^O>#ZD>'Q!%E!Q`````Q2'<WZU!!!J!0('5T'`!!!!!1V"<'FH<GVF<H1O9X2M!".!"A!*17RJ:WZN:7ZU!#5!]?%\/Q5!!!!"$5:P<H1A5WF[:3ZD>'Q!$U!&!!24;8JF!!!31&!!!Q!%!!5!"A25:8BU!!!51#%05WBP>S"-98FF=C"597)`!"2!)1^4;'^X)&2F=GVJ<G&M=T]!'E"1!!5!!!!$!!=!#!!*#&.F>(2J<G>T!!!"!!I!!!!!!!!!'ER71WRB=X.1=GFW982F2'&U962B9E^S:'6S!!!!43%!A!!!!!!#!!5!"Q!!$!"!!!(`````!!!!!1!"!!!!#A!!!!!!!!!"!!!!!A!!!!-!!!!%!!!!"1!!!!9!!!!(!!!!#!!!!!E!!!!!!!!!'UR71WRB=X.1=GFW982F2'&U962J<76T>'&N=!!!!"EB!)!!!!!!!1!&!!=!!!%!!/*99[M!!!!!!!!!*ER71WRB=X.1=GFW982F2'&U95RB=X2"=("M;76E6'FN:8.U97VQ!!!!'3%!A!!!!!!"!!5!"Q!!!1!!YFBDKQ!!!!!!!!!;4&:$<'&T=V"S;8:B>'6%982B6(FQ:52F=W-!!!&D)1#!!!!!!!%!#!!Q`````Q!"!!!!!!&(!!!!#Q!A1#%<476S:W5A>8.F=C"M98FF=H-A<WYA9W^N<7FU!#"!)2J4>'^S:3!T=G1A='&S>(EA6'6N='RB>'6T0Q!!&%!Q`````QN'<WRE:8)A4G&N:1!?1&!!!A!"!!)4-X*E)("B=H2Z)&2F<8"M982F=Q!D!0%!!!!!!!!!!1B'<WZU,G.U<!!31$$`````"%:P<H1!!#E!]=:4-<]!!!!"$5&M;7>O<76O>#ZD>'Q!%U!'!!F"<'FH<GVF<H1!*1$RY4M\"1!!!!%.2G^O>#"4;8JF,G.U<!!01!5!"&.J?G5!!"*!5!!$!!1!"1!'"&2F?(1!!"2!)1^4;'^X)%RB?76S)&2B9D]!&%!B$V.I<X=A6'6S<7FO97RT0Q!C1&!!"1!!!!-!"Q!)!!E15W6U>'FO:X-O<(:D<'&T=Q!!!1!+!!!!!!!!!"Z-6E.M98.T5(*J>G&U:52B>'&%:GRU2'&U96.J?G5!!!!:)1#!!!!!!!%!"1!$!!!"!!!!!!!Q!!!!!!!!!"J-6E.M98.T5(*J>G&U:52B>'&%:GRU2'&U91!!!6YB!)!!!!!!#Q!A1#%<476S:W5A>8.F=C"M98FF=H-A<WYA9W^N<7FU!#"!)2J4>'^S:3!T=G1A='&S>(EA6'6N='RB>'6T0Q!!&%!Q`````QN'<WRE:8)A4G&N:1!?1&!!!A!"!!)4-X*E)("B=H2Z)&2F<8"M982F=Q!D!0%!!!!!!!!!!1B'<WZU,G.U<!!31$$`````"%:P<H1!!#E!]=:4-<]!!!!"$5&M;7>O<76O>#ZD>'Q!%U!'!!F"<'FH<GVF<H1!*1$RY4M\"1!!!!%.2G^O>#"4;8JF,G.U<!!01!5!"&.J?G5!!"*!5!!$!!1!"1!'"&2F?(1!!"2!)1^4;'^X)%RB?76S)&2B9D]!&%!B$V.I<X=A6'6S<7FO97RT0Q!C1&!!"1!!!!-!"Q!)!!E15W6U>'FO:X-O<(:D<'&T=Q!!!1!+!!!!!!!!!!!!!!!!!Q!!!!!!!!!!!"2/33Z-6CZ"<'QO5W^V=G.F4WZM?1!!!"5B!)!!!!!!!1!%!#%!!1!!!1!!!!!!!!!!"!!1!!Q!!!!%!!!"0Q!!!#A!!!!#!!!%!!!!!#=!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"^Q!!!Z6YH*63Q7\41""^C:UUREE4[A+FJ?WGJ3V=IE+00>1)+3>!&=[B2Z:Y%SSNP:'^+3UH`I?0[+X`5@YA8Q#TNEF5U5LAE6@;W4=T<^Y-A*@9R1T&6WHU6;*\1SWRYB`_IM]W$A/;81?PLASE^5:'YS17*=\T[X$G,ORB>H.]8-O"*J1&U4?2!^N_$<;Z!=TP<LQ8[6CQ;3:3*PGF3$/G%D:5=2RJ]\Y?;*5+>J3'<-*4@=E')JZ)LE6W!KQ7X.S_EC(&@_#RQ*:`CCJMV,Q\9KC<5VC'&+LW1&RIE[0<$L[IL_S>K=Y'`00*QD=1;2QF8&+R-]R_HAV`5'SV%QCNIW3=^?4Z50)M;]Y>JM(86+.'6?J91A0/ZFMZT43F6C/7I^EED=[*$1OZZI1EE2YA"+QVO(FA==527H$]*6AD/5<$`W[JD\JQ#$6#*__ED1Y?7N.Q2"VXK6KO"]5<$4SM9P/OE4:,W0;^QX3)P(G_:Y3/Y>S%)@!94\"'AJG704T#5TI^3V_%*9E6L'0ZVAKV<S_+OVC(9DD0C027/:T?8-LN@Z+S#DLKZKC!!DY2>RN^)M*)H2W3V^AO[@L(X.,_^CR?HO>7T+2#C^X\L`H;&,62<"TF;'+:<AT\/-!,_A^)SQ<F=?FVBT!NGBEI-WE#[T?"--.$!!!!!(=!!1!#!!-!"1!!!&A!$Q1!!!!!$Q$:!.1!!!"B!!]%!!!!!!]!W1$5!!!!;A!0"!!!!!!0!.E!V!!!!(/!!)1!A!!!%(``!!%!!!"VA!#%!)!!!""``Q!"#&.F:W^F)&6*#&.F:W^F)&6*#&.F:W^F)&6*!4!"-A"35V*$$1I!!UR71U.-1F:8!!!B8!!!"&5!!!!A!!!B0!!!!!!!!!!!!!!!)!!!!$1!!!2)!!!!(5R*1EY!!!!!!!!"<%R75V)!!!!!!!!"A&*55U=!!!!!!!!"F%.$5V1!!!!!!!!"K%R*>GE!!!!!!!!"P%.04F!!!!!!!!!"U&2./$!!!!!!!!!"Z%2'2&-!!!!!!!!"_%R*:(-!!!!!!!!#$%>$2%E!!!!!!!!#)(:F=H-!!!!%!!!#.%>$5&)!!!!!!!!#G%F$4UY!!!!!!!!#L'FD<$A!!!!!!!!#Q%.11T)!!!!!!!!#V%R*:H!!!!!!!!!#[%:128A!!!!!!!!#`%:13')!!!!!!!!$%%:15U5!!!!!!!!$*&:12&!!!!!!!!!$/%R*9G1!!!!!!!!$4%*%28A!!!!!!!!$9%*%3')!!!!!!!!$>%*%5U5!!!!!!!!$C&:*6&-!!!!!!!!$H%253&!!!!!!!!!$M%V6351!!!!!!!!$R%B*5V1!!!!!!!!$W&:$6&!!!!!!!!!$\%:515)!!!!!!!!%!!!!!!$`````!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(!!!!!!!!!!!`````Q!!!!!!!!$!!!!!!!!!!!$`````!!!!!!!!!.1!!!!!!!!!!0````]!!!!!!!!!X!!!!!!!!!!!`````Q!!!!!!!!)Y!!!!!!!!!!$`````!!!!!!!!!E!!!!!!!!!!!0````]!!!!!!!!#;!!!!!!!!!!!`````Q!!!!!!!!+Y!!!!!!!!!!$`````!!!!!!!!!MA!!!!!!!!!"0````]!!!!!!!!#Y!!!!!!!!!!(`````Q!!!!!!!!,Q!!!!!!!!!!D`````!!!!!!!!!Q!!!!!!!!!!#@````]!!!!!!!!$%!!!!!!!!!!+`````Q!!!!!!!!-A!!!!!!!!!!$`````!!!!!!!!!T!!!!!!!!!!!0````]!!!!!!!!$2!!!!!!!!!!!`````Q!!!!!!!!0)!!!!!!!!!!$`````!!!!!!!!"]Q!!!!!!!!!!0````]!!!!!!!!(V!!!!!!!!!!!`````Q!!!!!!!!F1!!!!!!!!!!$`````!!!!!!!!#71!!!!!!!!!!0````]!!!!!!!!8_!!!!!!!!!!!`````Q!!!!!!!"A!!!!!!!!!!!$`````!!!!!!!!'!A!!!!!!!!!!0````]!!!!!!!!9'!!!!!!!!!!!`````Q!!!!!!!"AA!!!!!!!!!!$`````!!!!!!!!')Q!!!!!!!!!!0````]!!!!!!!!9F!!!!!!!!!!!`````Q!!!!!!!"[)!!!!!!!!!!$`````!!!!!!!!(J!!!!!!!!!!!0````]!!!!!!!!?G!!!!!!!!!!!`````Q!!!!!!!"\%!!!!!!!!!)$`````!!!!!!!!)-!!!!!!$&.F>(2J<G>T,G.U<!!!!!!
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!#I^5F.31QU+!!.-6E.$4%*76Q!!*7Q!!!42!!!!)!!!*5Q!!!!6!!!!!2"4:82U;7ZH=SZM>G.M98.T!!!!!!!!I#%!A!!!-!!!+!!%!!!!!!1!!Q!]!,Q!(U!!!A!!!!!"!!%!"P````]!!!!!!!!!!!!!!!#180%L$W\G4ZT=.2U]R=/S!!!!$!!!!"!!!!!#([I@;4G/ZEG!3]]`?3WT>N1>D.G0!,)%[9!*G/TY1HY!!!!!!!!!!%#I*-7B[.>'K%B$F)PR+MU"!!!!`````^1>D.G0!,)%[9!*G/TY1HY!!!!1SWK0)I;]L[=WTK]7]$9D^A!!!!1!!!!!!!!"6A!"4&:$1Q!!!!1!!F:*4%)!!!!!5&2)-!!!!!5!!1!"!!!!!!)!!F:*1U-!!!!!!1B'<WZU,G.U<!"16%AQ!!!!.Q!!!!5(0(:J<'FC0B"-97*73568)%FD<WYA16"*"WRW8WFD<WY)1W^O>(*P<(-)2G^O>#ZD>'Q!!!!!!!&#!!!!!!!#6EF$1Q!!!!!!!1V"<'FH<GVF<H1O9X2M5&2)-!!!!$Q!!!!&"TRW;7RJ9DY14'&C6EF&6S"*9W^O)%&131>M>F^J9W^O#%.P<H2S<WRT$5&M;7>O<76O>#ZD>'Q!!!!!!!*#!!!!!!!#6EF$1Q!!!!!"$5:P<H1A5WF[:3ZD>'R16%AQ!!!!/Q!!!!5+0(*F=W^V=G.F0A>Q<(6H;7ZT$%Z*37.P<E6E;82P=AB$<WZU=G^M=QV'<WZU)&.J?G5O9X2M!!!!!!!$1A!!!!!!!Q!!!!!!!A!%!!!!!!!D!!!!'HC=9W"H9'VAO-!!R)Q/4!V-#5$7"Q9'DA!'!%J4":I!!!!!&!!!!"2YH'0A9/"BY%#"$!!$=!".!!!!3A!!!3:YH'.AQ!4`A1")-4)QM#1!;29U=4!.9V-4Y$)8FVV1=7;I'VG2Z:DBCI$M&U#;#31)V7%!E7)R10)=(0"$[1N)9A$$GC?,!!!!!!!-!!&73524!!!!!!!$!!!"CQ!!!]RYH&P!S-"18G&G%M$%Q-!-:#MS.$!EZ[?E]D)!_1Q)E),-)1-U1-X41B-X0(!Y$1DU_/6<Q(S0ZD=;HMU`G%I&08<!V0S`Y.&]2//Q2X=D3/CY1Q*994?DY368QQ0`*VQ!;Q-KY*>X!/PX[4TAO1OG';D%I`/A4_=JR`_8Q+L3-/RLK,2G+'%(KA.*(W`]QAD2C?%!=MXX/0C)R2.OG&=P#Z.8MAC42[=,F]&R&[Y!-:#S8B%OL0;&!1V1]/A]BZ$=R1B2U=W(%00I>!R!Y7EA]RIPI0A'+0!"8?!"*!Q6YAZD2BV*9/XL?\N9A41<EJA$!S4_(:B1M2Y$)Q0)-S"S,F3N$:$.""74A9K"W,T13.&!UK-&&7.CM)?,2=,V)-2W)LE$*P9+<"<%8;R1-4OAZ!9IWY=2)A>C2Q(:$[$M<#"<!-KO!<)6'#&_97$!44P\O\D#W-A!FK>A75M;C*.T#QQ-^+K>>)!IO&;H/FCH.&SHV+F7R[G711IE8Z"=BE/;!1$DTZI`!!!!!9A!!!+)?*RT9'"A++]Q-R&A9G"A:G2A5'2I9%D/4UFF1!-O4/AC%"!7(OT2`#<!I^.(R=/D-U4&I='3Q:&`[I%'+R"VU+8TA)P"#6?$%[6'(LW/("[>,E"FP56!2IG+!YBH!7):.&2S-!"6.V3"K%/>*QQO'&QMY46BZ.^WQ+0Z3%"U@.RBDW[1YFY0$J"6&B\>)3I'(LV?9*["2T>1O$O)QW-XT&H`,XNU(D1]]0]E`Z3$*3Q>*V\PW0]@#%#'!/XX%)#Y&WC)!^!V!F$8_+BIA&A+1/-%A-9*1!VB0!]SB,XDR-M#K"%;-(>I?(4\!.8X"H+!`+\!PTW!Q`"!GH5A"V"(;1*-+2/+5C;QUKY!*M-$6I&-))8G[-\S!4EL5!!3HB5#$+$QL!22"QU/.HQ%BML"FU```@]0>.%^))5^9MA%;V`@WQ6-"AS-3')/1+T%)-%!%_^(%A=":X]86Q9M[1/7:E"[J)%Y/<@!Q%#PWEE(C)*L>;K$>5L$>5K>;H7=;BE!R__EB!!!!25!!!))?*RT9'"A++]Q-ZH!S-$!$-3+$!U-S@EJK1RIY!ADOAA%B(EUPQHQ[022]@$I$&&R[',M90,I>A(S?DUY)-,>1''0XC)ALQ4)!!J:A&A'81Y=(5Y=),57-,57),5'(MW(/%"G'8BU!Y8XQ3T[@[XV!(`L,#!,:LY!EPH.BQ4!^I/%.%!M";"O!:#?UCS1?AW9(2I?X4Z!S>Z!M"U+`.M>/.)[(4FA;JB1V$#"V81Z-(5Y-K(<[A0S63$%VCY(A1Z(!=-$(MV(!O)/9Q]I)M(;V`>WA9);/<A>A$A,+!)44U13"Q&H@R@8"CTR!YMT%#5&R-E&S76[V5Y[1"2=KV->L&-;LF0K6+PD6-P!!!$:XGK%!!!!!!!!%Q!!!!FYH'.A9'"E:!!#!!!5!!-!!!!!$C%"A!9!!!9S-3YQ,D%!!!!!!!!-)1#!!!!!"$)R,D!!!!!!$C%"A!9!!!9S-3YQ,D%!!!!!!!!-)1#!!!!!"$)R,D!!!!!!$C%"A!9!!!9S-3YQ,D%!!!!!!!!5!1!!!068.9*Z*K+-,H.34A:*/:U!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!)$`````A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!!!!"A!!!!9!!!!'!9!!"A:A!!99'!!'9!9!"I!"!!<!!Q!'M!U!"IQ\!!;$V1!'A+M!"I$6!!;!KQ!'A.5!"I#L!!;!V1!'9+Y!"BD9!!9'Y!!'!9!!"`````Q!!"!$```````````````````````````````````````````]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!#ZO1!!!!!!!!!!!!!!!!!!!!!!!!!!``]!!!!!!!#ZU=8,U<E!!!!!!!!!!!!!!!!!!!!!!!$``Q!!!!#ZU=7`P\_`S^'Z!!!!!!!!!!!!!!!!!!!!!0``!!#ZU=7`P\_`P\_`P]P2O1!!!!!!!!!!!!!!!!!!``]!S]7`P\_`P\_`P\_`P\`,U1!!!!!!!!!!!!!!!!$``Q$&R<_`P\_`P\_`P\_`P``,!!!!!!!!!!!!!!!!!0``!-8,S]7`P\_`P\_`P````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P&P\_`P```````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,R>(````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P,`````````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]P`````````R1!!!!!!!!!!!!!!!!$``Q$&S]P,S]P,S``````````&!!!!!!!!!!!!!!!!!0``!-8,S]P,S]P,`````````]5!!!!!!!!!!!!!!!!!``]!R=P,S]P,S]P`````````R1!!!!!!!!!!!!!!!!$``Q$,S]P,S]P,S````````]P,!!!!!!!!!!!!!!!!!0``!!$&R=P,S]P,`````]P2R1!!!!!!!!!!!!!!!!!!``]!!!!!R=P,S]P``]P,R1!!!!!!!!!!!!!!!!!!!!$``Q!!!!!!!-8,S]P,PQ!!!!!!!!!!!!!!!!!!!!!!!0``!!!!!!!!!!$&PQ!!!!!!!!!!!!!!!!!!!!!!!!!!````````````````````````````````````````````!!!!!A!%!!!!!!&X!!&'5%B1!!!!!Q!#6%2$1Q!!!!%)2G^O>#ZD>'Q!5&2)-!!!!$=!!!!&"TRW;7RJ9DY14'&C6EF&6S"*9W^O)%&131>M>F^J9W^O#%.P<H2S<WRT#%:P<H1O9X2M!!!!!!!!1A!!!!!!!!!"!!!!L6"53$!!!!!!!!!!!!!#6%2$1Q!!!!!!!1V'<WZU)&.J?G5O9X2M5&2)-!!!!$M!!!!&#DRS:8.P>8*D:4Y(='RV:WFO=QR/35FD<WZ&:'FU<X))1W^O>(*P<(-.2G^O>#"4;8JF,G.U<!!!!!!!!%)!!!!!!!!!!1!!!.:16%AQ!!!!!!!!!!!!!F2%1U-!!!!!!!%.17RJ:WZN:7ZU,G.U<&"53$!!!!!]!!!!"1=]>GFM;7)_%%RB9F:*26=A37.P<C""5%E(<(:@;7.P<AB$<WZU=G^M=QV"<'FH<GVF<H1O9X2M!!!!!!!!1A!!!!!!!!!"!!!![6"53$!!!!!!!!!!!!!$!!!!!"!!!!!$!!!!!!!!!!!!!!!!!!!/<Q!!+D:YH-6;@8!<R28@EW6&EOV95GT(!I)P\EGE.%HT!32.#*"9DEHCDR$:B'9[E)NUNG]C[=TJZ/"U*D!A$'["4*M3/GF#[1R./U.4;!-FU,1%%!%K7BB+5TY[9^)`G%H4FB:#9>,)V\?\^SH*6N**Q*YZ\<\>NW^XX_`^>P@W%,J]E;`:-9&W&"$D_Q13H18ED?=:B(,TX%D\#Y]C8R`T8]1U"*E#OM\>ZXP0-=&=5E#V]8T9P3!SBPY&N>6(V-O9C^!^PO.1V?5,1G0?!KK0ZW@[VX,D0O\R3\CR;LV60ZLFOZ_:=.T%N8TKPD]LA5'5H9/@`HH-"')CMZX/</N[0C6E/3TVT(-(3:/?!P*&]H5S.XY:N!CG8S".-DW-S'T7GU41Z"RU]/""5]F0F=+E'UN"BR&";TP4-Y6/)*+@F?<'ZR)>,^%"/^NV/Z'7C6WY\VCJ7(6'*/]$6>#\42MSVN8V#N=2066611_?GNZA!46QY[P=1@@R_,P6>4>EHU9-9H+XO.6(V1.9X^_.P5$K"M!2%@"4;"HDCU)_7E#8:`//T=C*84%"^FTI#('&5X@&V?!+:D6RB3=SZE/G,X:6]%8%G7O>V:<)J"6":K6_.J<AUWFW3";(?56AY\T#FXJJ234P79*H!"MD!%'.S-EYU7(LD%NI``\^-!HQ.&7P!>7:X,CBZY@2O'%U_KT(T6H(6MX:OR:G,`*:\Q#?Q>!SBYZ<*](N3P*=4*[\S(0-20)C1,,@6^R2'Z+PR..X@J&]&1"M2R'3U3(U)8JV#F1OI5IGEK%_Y!1>GE*H+?D=<E5S["Q#H6=L)`FL*5D'OE6)XLV\NUU0@,(-1,+493C3MW_I:^1T'-^Z^2CT!0W.Y*HCMQ@=%=]\%9O.P!Z'XE?C(<[(]0RXE0FP./%\(2QA[C-`6>9"L!.2#.>("[6N<+]A*]55HUB@3RXC#^'AALK)G].EPQT#7OBZS0"581%^%]_\ACFOP-FCP!L6IQ:UD1X/Z70(V<.[^6>\OC?XNY,;S]W@JF86,.=5U,-1$&>QYYX9IJ0AL9[3BL_&IF.TY.N925P`W:)_:EH`S5Q8IJ<U"H@1UW+[\N@AON$857A4CHR7?T5.JCI)JN'<52WKU_I"Y?S+ZSH@I%X1M>="&4;(04AJXQ3HDBD722S7<?U6<F.+IW:X+<0-B+GZ&4V:E6E?+G+7'>"URE1T:2;T0_;5\,"-C=YP4JV@KAC<(#$0%_2ZT'37(^C92?_ID6HWH2^G+1+7$=)Q^I>B"3QBGS@!>=^012Q`J%I7MM'OXIK?G%,H5>#RE]UGM,.6NT-6W@S9SR>RT3<>F-YVZ<TT%]-\J9RT#B!+D$/GPA<B_B:B(!@2_VE"P28*.S-.GOKT[CHVLWA0=1WN%1>(=HG7>G5(!CT:!@[W"P!.E=><VNI20L0CCJJND9L<SXOO$!7"N8>UF&RY;_M,$'TN8!B&RFP79D-"5*O$ZJ$B4^-[R0BRBTJB_':]K`^%1%VG@]I4]P]R?K:"-_9L-?;J;)RL27>L[@U#UQA=M9A<^VLIR1(`$@KI)CWK8\0E*:;]ZDK4H9XO=+,=FYBDI'`5LH=+OVEF.(^"PU(X4&-E(Q3[>R$LT>>2[T.2$1I4C\8%9B0B`CK$P\^LY@)(,/EO#[^$WT.JWV7E\99\=.MVU(<$F'V`R^,?`::UJ[6N4Y&JBF#S-CP_;Q,%[#(`2`O5'<(,",E]9S(8PPNQ#0MW1?(T";</XYSD-2?=B?'#NZ\+I-!KM#SQ9IKER:C5GJ].YG*0MXN4;&FV?.12:F&YNBJON6$%OR9<>?MIA<O!Q/^O/,Z]?@5(/\7;%0)HD*"([$+UQR\S*S=0_?56&D6^&_*:G2!(5EEBJ:R$]0^^]O#`=(:BWPZ2.'V%PL(!,-"\.1M^?)WJUF=VZFL=Z7Z#$Z=9%;P_"X9O;I8^'FH_O8/)7L#W2,0GO`$7A#/7QP!^;QF*[.:1.2I'R)^/BHBKDB!%?W[M5&>A9"0OO9I<L[6LN]&*-R!`#3=BUVS%KTCQX0S!-S(U+[Y9I%/1KW6R9&!R?7.:.M][05WQ-&ODOR%JGKE7OG*KYTZJ)9G6^IXF9R9UV:SC14D.'K`_E^!5]JSE27Y3HU?D#Z`$]?E_<M<I!2KD[LX)L@Y=07K0U=@,RWA6R-KF:R-L8,:VN82/U@F%_?C]5":B*H^2,C[@+K!HL3NW'/UF-_07_XH9$%H,)FI&#V6NR:XG:!&30"?`-10RQNC!-^%?#!=Y8^:4%WZ['(0#`MY,W]JXXPU,<#MTIY]18$JV,(\[CIH,4V_WJ)^;UC`:&ETU7XLW[K&WDN#Q_R<-\2[Q=`DQ9<!$4\O>QK!&`Q/7^.77^(+,H1=,[,FYHP5MY-:L<(O/+IDP?SPN/:RUT]&6J"4OC-@=:\^1>!\#@QW!&JW\XCS\7H^11#`'][V-,9!M9OEK^NB$'N<I\P$.!HI*;PJB]O+W&U!/^$UU2CIS?F^?BLZM+_+7W^%^*1.P*(VJ*.O$BSH78A(6KW(;--9_6$^1T[CH\5>!YYBB96_!'*9!HBYW*_463(\7-$E=?@4$53-;A]\OM9+7\)^-J>]:<W)]WO(I,GW!E_PE17=</2RZN-02869\5RW/8I02^B5>8H><H0:77579JN`DE(36/YB\+I8EO;S,1%N`M/\EZF%7^Y2(K^L:_<[\KU"D2P9LW)H_:`1FIWIM^-O*U-'*U*.-[#F%_B!A@@#(WB;(@O6L0Y3?#TW.;/TASCJ5*N6=>'J$B[!8HG@](Z'6YS0`R_4X9`]JK0ZNQ!(()M]J<D`DOV0@">Q:K-7$]*&F+R*%/\EAYW\RM:$>G1N7LZ2&0J%,VJ"@>F7#DWX."<V;4EL%=U'`G7(8+(R#D/7#N627F/XG:6H;:GD1L.:+=YH-U*ZB+^+F0CLN3]'?.S[Q86%QMUK3NL)L5YJY;Y9(-^;M<K:%:JKR&?F3UEC34\%^5$7KD#3%8,#J2+;V0KN]A>&9=WGZ8B4!2?F")>(02E?37[1%OQ4'O%LGYQFBB,W?4U%LP7WZY,1WK,^&&G'U7EKT0=/;.:K>LENV16-<HY1]TY::0>8&+Y/E/:IVGD/TVO;I6">!>V*R8O;*0EG:_G<7KE_FJD\MM4,S##[C+<:$5A;*0_Q#L>W,SEC.VBK,#H6Z8:O5B'S54[5*5!+WP.;SOUV+J;5%HS<V;6)L;L$FD7<L$<%O]7+*QA/'?+W9:L2WGIIE*MIM"<L-V3<*7Q1=?T3BN2'QZ+Q$*%)D/.KED#Q+-LNQQ>S&C_9OP*+U1E8>QD:,"=BJ$=]M&JH9N*9987Z0+T+@'B!3%NM?&^*J'((4;J"M4="B6(.!FR!8-UE)D0)&:H^8SY+1*A%2D=HCE%*&K>CAFG?\?M&$(1#>J*3#TN<J3;XT^5<?1&9(HV(YJ)B4AC109)`5;CE>I^;MC6&>;H3O)S&N!;LJEF*3?IC0!10Y.2&"5&31R8\=O#;DW59NWZ?'C6O$$R,^2.7V*AFNQ!!^;T.C4.#C?BUP+_*7[',./FF-+U++SKM\)4:"/LUT%R0D0%M""[U%.1%GBGWSK)CJ!:0)N$,3/9U@!:I!^*[-EA#;!6^$:I01,_!J&GSD;,+8$!ER9&E&YP.3+$!LMEPH;N#[9O\#J8-881&>QB5G+8.X^<,NNSG9*VR>!"K]J$2UC4&:3EP^CKU$U\J%$+Q%LAE>FV0A!$TTSMC1!//8U_)QDWM.9[_*W7#XG)+]"``I#^*[0M($D%BMJUDV9&AF-JWSSR?9F&V;<C"M04]U)G?!,^TLM>.)2[IX]0SQC(]F)(I9B)\H_KAQ)/%2J/*#+CVA6CG3[$R%R8VL!/6[5O=B7^\E)5.M=%>U5-YIU)W;;**0*&B]HI*_4IO/*0JZA83,,$+!"'WV+@7:KZ=@B$&!'T3B2VKPE"T+J+H0#%DL?]7EE#<EI!W[I5CCK6Z=4GSO4-7FRO[B6R;W:'+$AE,)WW`.[MN[C=S-"FO2,KXOT1!+95:O&/1YDRV8K[6U<L"G47\1J=:%XSC,M++"VT:'?W^JWS\%N'2\;C#B*4'2;=E/15ZK3>S#FIQ/]8K&[$;-$0>'95M=1BJ=ZNE)PR';LM&J)G=8W8+,X;SX.FQX%:Y_%;CH/\W^(,P87R`Q1?Y"OO`T_A*_P"PU_A-"]BMQ>[I`MOZ5^VH?/;+H^(?/^3O(?4("<Q'+\K>IKC;IIO]:P?&22`P.<%?Y71U%3?N"ON_N#9]C`,\#UWUZC\D@/ZIRPK=Q<^!7'V@W=($!FRV<,748K&NP7MLN"SL4-7SX&W#,BWB-5QBMA7UK68;JXFL^2[U3-6L^3[SFSJX14DK(B:XVXG3KV7PV*TE'OU<Z"HX,R-O[(E-AVXU8;:&DX`V`3^Z7\/^K)6[-!5NW"^*4>H+U#L7T_PF>7ZM?4G<!89[><N4(5YX&BS=\<#0"J/@EN`UR1X:^J>`@PK/WAZ?N&S=X9$_!1@O5_I:_#5P.E_``W41L<D,#&<MRI)#/_^_'3R-WI+[+?F\X[;!1@=_8\XMZ0;'<;]_WE%/X/)(<"Q8OT!@!X1[[;;IN#<AT<<XY#AU[>0AUVY7NZF/,-=FFD"/FAG(O?C?/6Y&+XR_&,IGQY;EH6Q@.=K^5"%[N^IK']$0E[A\^PZ[O:*P^(9?T:PY=(Z&U5632<9-KRV,J^LX",0OTR@S/=;GT``TT8Y-J^L4,>]LF&R)1+`LD4]_G_1/^"D>L^W4/L8R]\SWZO,OQ2Z1'!T_'S1Y%=%/=V++49G*:.C]3=?Y,`LPT$`L@H]`<?WD0`KT]Z`53[C(NUU(6H_KN"5'LZWM(F\!46'WA*(@'PQV,D8O.N^_W"^B;7WS<X0`5HOG0%N:[\4U-S_Q>THG-XN;8%X`Q^>N2J*!!!!!!1!!!#=!!!!"!!!!!!!!!!-!!%B1!!!!!!!$!!!!"!!!!!!!!!"F!!!!>8C=9W"A+"3190L(50?8A5HA+Z!B`:?"7>#0]4=$![?@Q'%AT3AA#237`=P!,KA.&N9_IMP"!!7K<)Q=EBS("4H!-BQN'AT```^8+7,E_(LE'FT2%2]Y5W770)=%!'5)':I!!!!!!!!%!!!!"Q!!";Y!!!!)!!!!)6^O;6^-98.U3WZP>WZ0>WZJ<G>-6E.M98.T1WRV=X2F=A!!!6MB!)!!!!!!!1!)!$$`````!!%!!!!!!4]!!!!,!#"!)2N.:8*H:3"V=W6S)'RB?76S=S"P<C"D<WVN;81!)%!B'F.U<X*F)$.S:#"Q98*U?3"5:7VQ<'&U:8-`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!%!!B-T=G1A='&S>(EA6'6N='RB>'6T!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!+1$RRF-RPQ!!!!%.17RJ:WZN:7ZU,G.U<!!41!9!#5&M;7>O<76O>!!F!0(B/TM&!!!!!1V'<WZU)&.J?G5O9X2M!!^!"1!%5WF[:1!!%E"1!!-!"!!&!!9%6'6Y>!!!&%!B$V.I<X=A4'&Z:8)A6'&C0Q!51#%05WBP>S"5:8*N;7ZB<(-`!"J!5!!&!!!!!Q!(!!A!#1B4:82U;7ZH=Q!!!1!+!!!!!!!!!"2/33Z-6CZ"<'QO5W^V=G.F4WZM?1!!!"5B!)!!!!!!!1!%!#%!!1!!!1!!!!!!!!!;4&:$<'&T=V"S;8:B>'6%982B6'&C4X*E:8)!!!"*)1#!!!!!!!)!"1!(!!!-!%!!!@````]!!!!"!!%!!!!*!!!!!!!!!!%!!!!#!!!!!Q!!!!1!!!!&!!!!"A!!!!=!!!!)!!!!!!!!!"N-6E.M98.T5(*J>G&U:52B>'&5;7VF=X2B<8!!!!!:)1#!!!!!!!%!"1!(!!!"!!$DV2-K!!!!!!!!!#:-6E.M98.T5(*J>G&U:52B>'&-98.U18"Q<'FF:&2J<76T>'&N=!!!!"EB!)!!!!!!!1!&!!=!!!%!!/06%SI!!!!!!!!!'ER71WRB=X.1=GFW982F2'&U962Z='6%:8.D!!!"23%!A!!!!!!"!!A!-0````]!!1!!!!!"+1!!!!I!)%!B'UVF=G>F)(6T:8)A<'&Z:8*T)'^O)'.P<7VJ>!!A1#%;5X2P=G5A-X*E)("B=H2Z)&2F<8"M982F=T]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!)Q$R!!!!!!!!!!%)2G^O>#ZD>'Q!%E!Q`````Q2'<WZU!!!J!0('5T'`!!!!!1V"<'FH<GVF<H1O9X2M!".!"A!*17RJ:WZN:7ZU!#5!]?%\/Q5!!!!"$5:P<H1A5WF[:3ZD>'Q!$U!&!!24;8JF!!!31&!!!Q!%!!5!"A25:8BU!!!51#%05WBP>S"5:8*N;7ZB<(-`!"B!5!!%!!!!!Q!(!!A)5W6U>'FO:X-!!!%!#1!!!!!!!!!?4&:$<'&T=V"S;8:B>'6%982B2':M>%2B>'&4;8JF!!!!'3%!A!!!!!!"!!5!!Q!!!1!!!!!!-!!!!!!!!!!;4&:$<'&T=V"S;8:B>'6%982B2':M>%2B>'%!!!%`)1#!!!!!!!I!)%!B'UVF=G>F)(6T:8)A<'&Z:8*T)'^O)'.P<7VJ>!!A1#%;5X2P=G5A-X*E)("B=H2Z)&2F<8"M982F=T]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!)Q$R!!!!!!!!!!%)2G^O>#ZD>'Q!%E!Q`````Q2'<WZU!!!J!0('5T'`!!!!!1V"<'FH<GVF<H1O9X2M!".!"A!*17RJ:WZN:7ZU!#5!]?%\/Q5!!!!"$5:P<H1A5WF[:3ZD>'Q!$U!&!!24;8JF!!!31&!!!Q!%!!5!"A25:8BU!!!51#%05WBP>S"5:8*N;7ZB<(-`!"B!5!!%!!!!!Q!(!!A)5W6U>'FO:X-!!!%!#1!!!!!!!!!!!!!!!!-!!!!!!!!!!!!!"!!0!"1!!!!%!!!"0Q!!!#A!!!!#!!!%!!!!!#A!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"]1!!!Y>YH)V3WU\<1"!^]358%EC);5OBA1U5++B#6$TS5&?6]N9+V;D0N?*.;GHND?Q.FT\R:XXL(`!"6<]A8^$/LNV16&#\)^H;G4-T:_9MA"@9RAT&K>1(-F7(1S81^9^_UH'U!^D(\&PQ[KO',,Y2]4B.?)HT`#I;=R>W-0N_=O);I%ZF1@S&'W$<>_(I']$]`PI\HIUZG_9]9S+]YFH/:-K'-EFCJ?.LA:)::]>:R#:BJK\9'5]G)F1]@QWM&.S;!SECSH]@*BQ<`CEM/(#^?X*IGF09GB1MZYR@+FWDXQY_SQM#:5G=BI)+@]4MRYVX1$CL%X#FYH3=(YLTI1DTP$6X[''/K*Z$&;OII>Z\+[;Z)C*SR!S74<,YH0KS+&1B8$)M)!,M6@K\GICZYBAN.0Q;\*%9I_Z@W`+$+BR=DN!RH*@12M??2C0KVU=>:H,+V^.WY;&XHXCN%L<ZI'Q.IK\$$YD6U*R<U!1?Y4'?G!5[V(!&K_D;[D)K+3TD+:<O0*8WX1@2P*7^%'%>T^!L28AZ8_0'@[T2!HWK_F-"<?)4]89Q)"K-L%_%N'U2\>_W5.L@HNP)NL&#DQK?`U(JX]I[F,.6P#L;7"/,7+/>\G!8?[;#3T7+["\Z>IFTD4J:R,6#H4W+;1RV_Q8(0<TV!!!!!!!!>Q!"!!)!!Q!&!!!!7!!0"!!!!!!0!.E!V!!!!'%!$Q1!!!!!$Q$:!.1!!!"K!!]%!!!!!!]!W1$5!!!!=Y!!B!#!!!!0!.E!V!!!!(7!!)1!A!!!$Q$:!.1)5W6H<W5A65E)5W6H<W5A65E)5W6H<W5A65E"-!%S!&*45E-.#A!$4&:$1UR#6F=!!#6M!!!%U1!!!#!!!#6-!!!!!!!!!!!!!!!A!!!!.!!!"-1!!!!@4%F#4A!!!!!!!!'%4&:45A!!!!!!!!'95F242Q!!!!!!!!'M1U.46!!!!!!!!!(!4%FW;1!!!!!!!!(51U^/5!!!!!!!!!(I6%UY-!!!!!%!!!(]2%:%5Q!!!!!!!!)E4%FE=Q!!!!!!!!)Y6EF$2!!!!!)!!!*-2U.%31!!!!!!!!+)>G6S=Q!!!!1!!!+=5U.45A!!!!!!!!-!2U.15A!!!!!!!!-535.04A!!!!!!!!-I;7.M/!!!!!!!!!-]1V"$-A!!!!!!!!.14%FG=!!!!!!!!!.E2F"&?!!!!!!!!!.Y2F")9A!!!!!!!!/-2F"421!!!!!!!!/A6F"%5!!!!!!!!!/U4%FC:!!!!!!!!!0)1E2&?!!!!!!!!!0=1E2)9A!!!!!!!!0Q1E2421!!!!!!!!1%6EF55Q!!!!!!!!192&2)5!!!!!!!!!1M466*2!!!!!!!!!2!3%F46!!!!!!!!!256E.55!!!!!!!!!2I2F2"1A!!!!!!!!2]!!!!!0````]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=!!!!!!!!!!$`````!!!!!!!!!-!!!!!!!!!!!0````]!!!!!!!!!V!!!!!!!!!!!`````Q!!!!!!!!$=!!!!!!!!!!$`````!!!!!!!!!DA!!!!!!!!!!0````]!!!!!!!!#1!!!!!!!!!!#`````Q!!!!!!!!*I!!!!!!!!!!$`````!!!!!!!!!I!!!!!!!!!!!0````]!!!!!!!!#U!!!!!!!!!!!`````Q!!!!!!!!,A!!!!!!!!!!(`````!!!!!!!!"(!!!!!!!!!!!P````]!!!!!!!!&`!!!!!!!!!!!`````Q!!!!!!!!=9!!!!!!!!!!4`````!!!!!!!!"T!!!!!!!!!!"`````]!!!!!!!!(2!!!!!!!!!!)`````Q!!!!!!!!>5!!!!!!!!!!H`````!!!!!!!!"WA!!!!!!!!!#P````]!!!!!!!!(?!!!!!!!!!!!`````Q!!!!!!!!?-!!!!!!!!!!$`````!!!!!!!!"[1!!!!!!!!!!0````]!!!!!!!!(O!!!!!!!!!!!`````Q!!!!!!!!A]!!!!!!!!!!$`````!!!!!!!!$%!!!!!!!!!!!0````]!!!!!!!!-3!!!!!!!!!!!`````Q!!!!!!!!X%!!!!!!!!!!$`````!!!!!!!!$>A!!!!!!!!!!0````]!!!!!!!!=4!!!!!!!!!!!`````Q!!!!!!!"R5!!!!!!!!!!$`````!!!!!!!!(&Q!!!!!!!!!!0````]!!!!!!!!=<!!!!!!!!!!!`````Q!!!!!!!"RU!!!!!!!!!!$`````!!!!!!!!(/!!!!!!!!!!!0````]!!!!!!!!=[!!!!!!!!!!!`````Q!!!!!!!#+=!!!!!!!!!!$`````!!!!!!!!)K1!!!!!!!!!!0````]!!!!!!!!CL!!!!!!!!!!!`````Q!!!!!!!#,9!!!!!!!!!)$`````!!!!!!!!*.!!!!!!$&.F>(2J<G>T,G.U<!!!!!!
-!!!!!2"4:82U;7ZH=SZM>G.M98.T!&"53$!!!!!!!!!!!!!!!!!!$Q!"!!!!!!!!!!!!!!%!"A"1!!!!!1!!!!!!!!!!!!!"$ERB9F:*26=A4W*K:7.U!&"53$!!!!!!!!!!!!!)9)!"!!!!!!!!!!!!!!!!!1!!!!!!!1!!!!!$!"B!)2.498:F)%RB?76S=S"X;82I)&:*!"B!)2.4;'^X)%RB?76S=S"197RF>(2F!&)!]=4T;4E!!!!#%&.F>(2J<G>T,GRW9WRB=X--5W6U>'FO:X-O9X2M!#R!5!!#!!!!!2V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!)!!!!#``````````]!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!#!!!!!!5!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!'%!B%V.I<X=A4'&Z:8*T)&"B<'6U>'5!$E!Q`````Q64>(FM:1!B!0(%]CMQ!!!!!1F$<WRP=CZD>'Q!$U!(!!6$<WRP=A"7!0(%^+#@!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!Q1&!!"!!!!!%!!A!$(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!"!!!!!1!!!!!!!!!!@``````````!!!!!!!!!!""X!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!$!!!!!!E!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!'%!B%V.I<X=A4'&Z:8*T)&"B<'6U>'5!$E!Q`````Q64>(FM:1!B!0(%]CMQ!!!!!1F$<WRP=CZD>'Q!$U!(!!6$<WRP=A!I!0(%PC/=!!!!!1V$356@2G^O>(-O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!":!5!!$!!1!"1!'#62F?(1A5X"F9Q"9!0(%^+$,!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!S1&!!"1!!!!%!!A!$!!=>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!)!!!!"1!!!!!!!!!"!!!!!A!!!!0`````!!!!!!!!!!""X!!!!!!!!!-!!!!!!!!"$ERB9F:*26=A4W*K:7.U!&"53$!!!!!!!!!!!!!)9)!"!!!!!!!!!!!!!!!!!1!!!!!!"!!!!!!+!"B!)2.498:F)%RB?76S=S"X;82I)&:*!"B!)2.4;'^X)%RB?76S=S"197RF>(2F!!Z!-0````]&5X2Z<'5!*1$RR0)L-!!!!!%*1W^M<X)O9X2M!".!"Q!)2E=A1W^M<X)!!#5!]=4S+T!!!!!"#5.P<'^S,G.U<!!41!=!#%*()%.P<'^S!!!I!0(%PC/=!!!!!1V$356@2G^O>(-O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!":!5!!$!!5!"A!(#62F?(1A5X"F9Q";!0(%^+$O!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!U1&!!"A!!!!%!!A!$!!1!#"V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!E!!!!*!!!!!!!!!!%!!!!#!!!!!`````]!!!!%!!!!"1!!!!9!!!!(!!!!!!!!!!""X!!!1>Q!!!!!!!!$!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!5!!!!!#A!91#%45W&W:3"-98FF=H-A>WFU;#"731!91#%45WBP>S"-98FF=H-A5'&M:82U:1!/1$$`````"6.U?7RF!#5!]=4]81-!!!!"#5.P<'^S,G.U<!!41!=!#%:()%.P<'^S!!!F!0(%`&U$!!!!!1F$<WRP=CZD>'Q!%U!(!!B#2S"$<WRP=A!!+!$RR,YDH!!!!!%.1UF&8U:P<H2T,G.U<!!31$$`````"%:P<H1!!#.!&A!$"'RF:H1'9W6O>'6S"8*J:WBU!!F"<'FH<GVF<H1!#U!&!!24;8JF!!!71&!!!Q!&!!9!"QF5:8BU)&.Q:7-!7A$RR0R>"A!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!.%"1!!9!!!!"!!)!!Q!%!!A>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!*!!!!"P```````````````````````````````Q!!!!!!!!!!1>Q!!%(=!!!!!!!!!Q!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!'!!!!!!-!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!'%!B%V.I<X=A4'&Z:8*T)&"B<'6U>'5!5A$RR12.0!!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!,%"1!!)!!!!"(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!!A!!!!,``````````Q!!!!!!!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!=!!!!!!A!91#%45W&W:3"-98FF=H-A>WFU;#"731"1!0(&"%X2!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!K1&!!!1!!(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!!1!!!!%!!!!!!!!!!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!A!!!!!"1!91#%45W&W:3"-98FF=H-A>WFU;#"731!=1#%75W&N:3"'<WRE:8)A5X2S>7.U>8*F0Q!!&%!Q`````QN'<WRE:8)A4G&N:1!?1&!!!A!"!!)4-X*E)("B=H2Z)&2F<8"M982F=Q"3!0(&"7+S!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!M1&!!!A!!!!->1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!%!!!!!A!!!!$`````!!!!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!*!!!!!!E!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!(%!B&F.B<75A2G^M:'6S)&.U=H6D>(6S:4]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!$E!Q`````Q2'<WZU!!!D1"9!!Q2M:7:U"G.F<H2F=A6S;7>I>!!*17RJ:WZN:7ZU!!N!"1!%5WF[:1!!%E"1!!-!"!!&!!9%6'6Y>!!!6!$RR2$0`1!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!,E"1!!-!!!!$!!=>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!)!!!!"1!!!!!!!!!"!!!!!A!!!!0`````!!!!!!!!!!!!!!!!!Q!!!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!I!!!!!#A!91#%45W&W:3"-98FF=H-A>WFU;#"731!=1#%75W&N:3"'<WRE:8)A5X2S>7.U>8*F0Q!!&%!Q`````QN'<WRE:8)A4G&N:1!?1&!!!A!"!!)4-X*E)("B=H2Z)&2F<8"M982F=Q!/1$$`````"%:P<H1!!#.!&A!$"'RF:H1'9W6O>'6S"8*J:WBU!!F"<'FH<GVF<H1!#U!&!!24;8JF!!!31&!!!Q!%!!5!"A25:8BU!!!91#%45WBP>S"-98FF=C"197RF>(2F0Q"7!0(&'"^_!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!Q1&!!"!!!!!-!"Q!)(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!#1!!!!E!!!!!!!!!!1!!!!)!!!!$!!!!"!!!!!5!!!!'!!!!"`````]!!!!!!!!!!!!!!!!$!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!,!!!!!!M!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!)%!B'F.U<X*F)$.S:#"Q98*U?3"5:7VQ<'&U:8-`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!%!!B-T=G1A='&S>(EA6'6N='RB>'6T!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!$5!]1!!!!!!!!!"&F2F?(2@5X"F9WFG;7.B>'FP<CZD>'Q!&E"1!!-!"!!&!!9%6'6Y>!!!&%!B$V.I<X=A4'&Z:8)A6'&C0Q!51#%05WBP>S"5:8*N;7ZB<(-`!&A!]=6"1F]!!!!#%&.F>(2J<G>T,GRW9WRB=X--5W6U>'FO:X-O9X2M!$*!5!!&!!!!!Q!(!!A!#2V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!I!!!!+!!!!!!!!!!%!!!!#!!!!!Q!!!!1!!!!&!!!!"A!!!!=!!!!)`````Q!!!!!!!!!!!!!!!!-!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!-!!!!!!U!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!)%!B'F.U<X*F)$.S:#"Q98*U?3"5:7VQ<'&U:8-`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!%!!B-T=G1A='&S>(EA6'6N='RB>'6T!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!$5!]1!!!!!!!!!"&F2F?(2@5X"F9WFG;7.B>'FP<CZD>'Q!&E"1!!-!"!!&!!9%6'6Y>!!!&%!B$V.I<X=A4'&Z:8)A6'&C0Q!51#%05WBP>S"5:8*N;7ZB<(-`!"Z!)2B-<W.L)'FD<WYA>'6N='RB>'5A<'&Z:8)!!"J!)22-<W.L)'FD<WYA>'6Y>#"M98FF=A!!8!$RR5&-_!!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!.E"1!!=!!!!$!!=!#!!*!!I!#RV$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!Q!!!!-!!!!!!!!!!%!!!!#!!!!!Q!!!!1!!!!&!!!!"A!!!!=!!!!)!!!!#@``````````!!!!!!!!!!!!!!!!!Q!!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!.!!!!!!M!)%!B'UVF=G>F)(6T:8)A<'&Z:8*T)'^O)'.P<7VJ>!!A1#%;5X2P=G5A-X*E)("B=H2Z)&2F<8"M982F=T]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!)Q$R!!!!!!!!!!%)2G^O>#ZD>'Q!%E!Q`````Q2'<WZU!!!^!0(&[:T$!!!!!1V"<'FH<GVF<H1O9X2M!#>!&A!$"'RF:H1'9W6O>'6S"8*J:WBU!!F"<'FH<GVF<H1!*1$RR:'Q5Q!!!!%.2G^O>#"4;8JF,G.U<!!01!5!"&.J?G5!!"*!5!!$!!1!"1!'"&2F?(1!!"2!)1^4;'^X)%RB?76S)&2B9D]!&%!B$V.I<X=A6'6S<7FO97RT0Q"9!0(&[:T%!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!S1&!!"1!!!!-!"Q!)!!E>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!+!!!!#A!!!!!!!!!"!!!!!A!!!!-!!!!%!!!!"1!!!!9!!!!(!!!!#!!!!!E!!!!!!!!!!!!!!!!$!!!!!!!!!!!"$ERB9F:*26=A4W*K:7.U!&"53$!!!!!!!!!!!!!)9)!"!!!!!!!!!!!!!!!!!1!!!!!!$A!!!!!,!#"!)2N.:8*H:3"V=W6S)'RB?76S=S"P<C"D<WVN;81!)%!B'F.U<X*F)$.S:#"Q98*U?3"5:7VQ<'&U:8-`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!%!!B-T=G1A='&S>(EA6'6N='RB>'6T!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!+1$RRF-RPQ!!!!%.17RJ:WZN:7ZU,G.U<!!41!9!#5&M;7>O<76O>!!F!0(B/TM&!!!!!1V'<WZU)&.J?G5O9X2M!!^!"1!%5WF[:1!!%E"1!!-!"!!&!!9%6'6Y>!!!&%!B$V.I<X=A4'&Z:8)A6'&C0Q!51#%05WBP>S"5:8*N;7ZB<(-`!&A!]?*99[M!!!!#%&.F>(2J<G>T,GRW9WRB=X--5W6U>'FO:X-O9X2M!$*!5!!&!!!!!Q!(!!A!#2V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!I!!!!+!!!!!!!!!!%!!!!#!!!!!Q!!!!1!!!!&!!!!"A!!!!=!!!!)!!!!#1!!!!!!!!!!!!!!!!-!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!E!9(%!!!!!!!!!!!!!
+!!!!!2"4:82U;7ZH=SZM>G.M98.T!&"53$!!!!!!!!!!!!!!!!!!%!!"!!!!!!!!!!!!!!%!"A"1!!!!!1!!!!!!!!!!!!!"$ERB9F:*26=A4W*K:7.U!&"53$!!!!!!!!!!!!!)9)!"!!!!!!!!!!!!!!!!!1!!!!!!!1!!!!!$!"B!)2.498:F)%RB?76S=S"X;82I)&:*!"B!)2.4;'^X)%RB?76S=S"197RF>(2F!&)!]=4T;4E!!!!#%&.F>(2J<G>T,GRW9WRB=X--5W6U>'FO:X-O9X2M!#R!5!!#!!!!!2V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!)!!!!#``````````]!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!#!!!!!!5!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!'%!B%V.I<X=A4'&Z:8*T)&"B<'6U>'5!$E!Q`````Q64>(FM:1!B!0(%]CMQ!!!!!1F$<WRP=CZD>'Q!$U!(!!6$<WRP=A"7!0(%^+#@!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!Q1&!!"!!!!!%!!A!$(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!"!!!!!1!!!!!!!!!!@``````````!!!!!!!!!!""X!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!$!!!!!!E!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!'%!B%V.I<X=A4'&Z:8*T)&"B<'6U>'5!$E!Q`````Q64>(FM:1!B!0(%]CMQ!!!!!1F$<WRP=CZD>'Q!$U!(!!6$<WRP=A!I!0(%PC/=!!!!!1V$356@2G^O>(-O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!":!5!!$!!1!"1!'#62F?(1A5X"F9Q"9!0(%^+$,!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!S1&!!"1!!!!%!!A!$!!=>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!)!!!!"1!!!!!!!!!"!!!!!A!!!!0`````!!!!!!!!!!""X!!!!!!!!!-!!!!!!!!"$ERB9F:*26=A4W*K:7.U!&"53$!!!!!!!!!!!!!)9)!"!!!!!!!!!!!!!!!!!1!!!!!!"!!!!!!+!"B!)2.498:F)%RB?76S=S"X;82I)&:*!"B!)2.4;'^X)%RB?76S=S"197RF>(2F!!Z!-0````]&5X2Z<'5!*1$RR0)L-!!!!!%*1W^M<X)O9X2M!".!"Q!)2E=A1W^M<X)!!#5!]=4S+T!!!!!"#5.P<'^S,G.U<!!41!=!#%*()%.P<'^S!!!I!0(%PC/=!!!!!1V$356@2G^O>(-O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!":!5!!$!!5!"A!(#62F?(1A5X"F9Q";!0(%^+$O!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!U1&!!"A!!!!%!!A!$!!1!#"V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!E!!!!*!!!!!!!!!!%!!!!#!!!!!`````]!!!!%!!!!"1!!!!9!!!!(!!!!!!!!!!""X!!!1>Q!!!!!!!!$!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!5!!!!!#A!91#%45W&W:3"-98FF=H-A>WFU;#"731!91#%45WBP>S"-98FF=H-A5'&M:82U:1!/1$$`````"6.U?7RF!#5!]=4]81-!!!!"#5.P<'^S,G.U<!!41!=!#%:()%.P<'^S!!!F!0(%`&U$!!!!!1F$<WRP=CZD>'Q!%U!(!!B#2S"$<WRP=A!!+!$RR,YDH!!!!!%.1UF&8U:P<H2T,G.U<!!31$$`````"%:P<H1!!#.!&A!$"'RF:H1'9W6O>'6S"8*J:WBU!!F"<'FH<GVF<H1!#U!&!!24;8JF!!!71&!!!Q!&!!9!"QF5:8BU)&.Q:7-!7A$RR0R>"A!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!.%"1!!9!!!!"!!)!!Q!%!!A>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!*!!!!"P```````````````````````````````Q!!!!!!!!!!1>Q!!%(=!!!!!!!!!Q!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!'!!!!!!-!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!'%!B%V.I<X=A4'&Z:8*T)&"B<'6U>'5!5A$RR12.0!!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!,%"1!!)!!!!"(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!!A!!!!,``````````Q!!!!!!!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!=!!!!!!A!91#%45W&W:3"-98FF=H-A>WFU;#"731"1!0(&"%X2!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!K1&!!!1!!(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!!1!!!!%!!!!!!!!!!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!A!!!!!"1!91#%45W&W:3"-98FF=H-A>WFU;#"731!=1#%75W&N:3"'<WRE:8)A5X2S>7.U>8*F0Q!!&%!Q`````QN'<WRE:8)A4G&N:1!?1&!!!A!"!!)4-X*E)("B=H2Z)&2F<8"M982F=Q"3!0(&"7+S!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!M1&!!!A!!!!->1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!%!!!!!A!!!!$`````!!!!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!*!!!!!!E!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!(%!B&F.B<75A2G^M:'6S)&.U=H6D>(6S:4]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!$E!Q`````Q2'<WZU!!!D1"9!!Q2M:7:U"G.F<H2F=A6S;7>I>!!*17RJ:WZN:7ZU!!N!"1!%5WF[:1!!%E"1!!-!"!!&!!9%6'6Y>!!!6!$RR2$0`1!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!,E"1!!-!!!!$!!=>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!)!!!!"1!!!!!!!!!"!!!!!A!!!!0`````!!!!!!!!!!!!!!!!!Q!!!!!!!1Z-97*73568)%^C;G6D>!"16%AQ!!!!!!!!!!!!#'#!!1!!!!!!!!!!!!!!!!%!!!!!!!I!!!!!#A!91#%45W&W:3"-98FF=H-A>WFU;#"731!=1#%75W&N:3"'<WRE:8)A5X2S>7.U>8*F0Q!!&%!Q`````QN'<WRE:8)A4G&N:1!?1&!!!A!"!!)4-X*E)("B=H2Z)&2F<8"M982F=Q!/1$$`````"%:P<H1!!#.!&A!$"'RF:H1'9W6O>'6S"8*J:WBU!!F"<'FH<GVF<H1!#U!&!!24;8JF!!!31&!!!Q!%!!5!"A25:8BU!!!91#%45WBP>S"-98FF=C"197RF>(2F0Q"7!0(&'"^_!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!Q1&!!"!!!!!-!"Q!)(5.M>8.U:8)A<W9A9WRB=X-A=(*J>G&U:3"E982B!!%!#1!!!!E!!!!!!!!!!1!!!!)!!!!$!!!!"!!!!!5!!!!'!!!!"`````]!!!!!!!!!!!!!!!!$!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!,!!!!!!M!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!)%!B'F.U<X*F)$.S:#"Q98*U?3"5:7VQ<'&U:8-`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!%!!B-T=G1A='&S>(EA6'6N='RB>'6T!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!$5!]1!!!!!!!!!"&F2F?(2@5X"F9WFG;7.B>'FP<CZD>'Q!&E"1!!-!"!!&!!9%6'6Y>!!!&%!B$V.I<X=A4'&Z:8)A6'&C0Q!51#%05WBP>S"5:8*N;7ZB<(-`!&A!]=6"1F]!!!!#%&.F>(2J<G>T,GRW9WRB=X--5W6U>'FO:X-O9X2M!$*!5!!&!!!!!Q!(!!A!#2V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!I!!!!+!!!!!!!!!!%!!!!#!!!!!Q!!!!1!!!!&!!!!"A!!!!=!!!!)`````Q!!!!!!!!!!!!!!!!-!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!-!!!!!!U!'%!B%V.B>G5A4'&Z:8*T)(>J>'AA6EE!)%!B'F.U<X*F)$.S:#"Q98*U?3"5:7VQ<'&U:8-`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!%!!B-T=G1A='&S>(EA6'6N='RB>'6T!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!)U!7!!-%<'6G>!:D:7ZU:8)&=GFH;(1!#5&M;7>O<76O>!!,1!5!"&.J?G5!!$5!]1!!!!!!!!!"&F2F?(2@5X"F9WFG;7.B>'FP<CZD>'Q!&E"1!!-!"!!&!!9%6'6Y>!!!&%!B$V.I<X=A4'&Z:8)A6'&C0Q!51#%05WBP>S"5:8*N;7ZB<(-`!"Z!)2B-<W.L)'FD<WYA>'6N='RB>'5A<'&Z:8)!!"J!)22-<W.L)'FD<WYA>'6Y>#"M98FF=A!!8!$RR5&-_!!!!!)15W6U>'FO:X-O<(:D<'&T=QR4:82U;7ZH=SZD>'Q!.E"1!!=!!!!$!!=!#!!*!!I!#RV$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!Q!!!!-!!!!!!!!!!%!!!!#!!!!!Q!!!!1!!!!&!!!!"A!!!!=!!!!)!!!!#@``````````!!!!!!!!!!!!!!!!!Q!!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!BAA!%!!!!!!!!!!!!!!!!"!!!!!!!.!!!!!!M!)%!B'UVF=G>F)(6T:8)A<'&Z:8*T)'^O)'.P<7VJ>!!A1#%;5X2P=G5A-X*E)("B=H2Z)&2F<8"M982F=T]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!)Q$R!!!!!!!!!!%)2G^O>#ZD>'Q!%E!Q`````Q2'<WZU!!!^!0(&[:T$!!!!!1V"<'FH<GVF<H1O9X2M!#>!&A!$"'RF:H1'9W6O>'6S"8*J:WBU!!F"<'FH<GVF<H1!*1$RR:'Q5Q!!!!%.2G^O>#"4;8JF,G.U<!!01!5!"&.J?G5!!"*!5!!$!!1!"1!'"&2F?(1!!"2!)1^4;'^X)%RB?76S)&2B9D]!&%!B$V.I<X=A6'6S<7FO97RT0Q"9!0(&[:T%!!!!!B"4:82U;7ZH=SZM>G.M98.T$&.F>(2J<G>T,G.U<!!S1&!!"1!!!!-!"Q!)!!E>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!+!!!!#A!!!!!!!!!"!!!!!A!!!!-!!!!%!!!!"1!!!!9!!!!(!!!!#!!!!!E!!!!!!!!!!!!!!!!$!!!!!!!!!!!"$ERB9F:*26=A4W*K:7.U!&"53$!!!!!!!!!!!!!)9)!"!!!!!!!!!!!!!!!!!1!!!!!!$A!!!!!,!#"!)2N.:8*H:3"V=W6S)'RB?76S=S"P<C"D<WVN;81!)%!B'F.U<X*F)$.S:#"Q98*U?3"5:7VQ<'&U:8-`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!%!!B-T=G1A='&S>(EA6'6N='RB>'6T!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!+1$RRF-RPQ!!!!%.17RJ:WZN:7ZU,G.U<!!41!9!#5&M;7>O<76O>!!F!0(B/TM&!!!!!1V'<WZU)&.J?G5O9X2M!!^!"1!%5WF[:1!!%E"1!!-!"!!&!!9%6'6Y>!!!&%!B$V.I<X=A4'&Z:8)A6'&C0Q!51#%05WBP>S"5:8*N;7ZB<(-`!&A!]?*99[M!!!!#%&.F>(2J<G>T,GRW9WRB=X--5W6U>'FO:X-O9X2M!$*!5!!&!!!!!Q!(!!A!#2V$<(6T>'6S)'^G)'.M98.T)("S;8:B>'5A:'&U91!"!!I!!!!+!!!!!!!!!!%!!!!#!!!!!Q!!!!1!!!!&!!!!"A!!!!=!!!!)!!!!#1!!!!!!!!!!!!!!!!-!!!!!!!!!!!%/4'&C6EF&6S"09GJF9X1!5&2)-!!!!!!!!!!!!!E!9(%!!!!!!!!!!!!!!!!"!!!!!!!0!!!!!!I!)%!B'UVF=G>F)(6T:8)A<'&Z:8*T)'^O)'.P<7VJ>!!A1#%;5X2P=G5A-X*E)("B=H2Z)&2F<8"M982F=T]!!"2!-0````],2G^M:'6S)%ZB<75!(E"1!!)!!1!#%T.S:#"Q98*U?3"5:7VQ<'&U:8-!)Q$R!!!!!!!!!!%)2G^O>#ZD>'Q!%E!Q`````Q2'<WZU!!!J!0('5T'`!!!!!1V"<'FH<GVF<H1O9X2M!".!"A!*17RJ:WZN:7ZU!#5!]?%\/Q5!!!!"$5:P<H1A5WF[:3ZD>'Q!$U!&!!24;8JF!!!31&!!!Q!%!!5!"A25:8BU!!!51#%05WBP>S"5:8*N;7ZB<(-`!&9!]?06%SI!!!!#%&.F>(2J<G>T,GRW9WRB=X--5W6U>'FO:X-O9X2M!$"!5!!%!!!!!Q!(!!A>1WRV=X2F=C"P:C"D<'&T=S"Q=GFW982F)'2B>'%!!1!*!!!!#1!!!!!!!!!"!!!!!A!!!!-!!!!%!!!!"1!!!!9!!!!(!!!!#1!!!!!!!!!!!!!!!!-!!!!!!!!"$ERB9F:*26=A4W*K:7.U!&"53$!!!!!!!!!!!!!B!)!!!!!!!!!!!!!!!!
false
@@ -21,7 +22,7 @@
2
-
-
-
+
-
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!$@!!!!#1!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!#"!5!!$!!!!!1!#%W6S=G^S)'FO)#BO<S"F=H*P=CE!#!!Q`````Q!;1(!!#!!"!!9!1A!!#V2S:75A5G6G<H6N!&1!]!!-!!-!"!!%!!1!"!!%!!1!"!!&!!1!"!!(!Q!!?!!!$1A!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!+!!!!!!!!!!!!!!!+!!!!!!%!#!!!!!!
-1
0
@@ -32,7 +33,7 @@
-
-
-
+
-
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!&-!!!!#A!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!#"!)2N.:8*H:3"V=W6S)'RB?76S=S"P<C"D<WVN;81!-E"Q!"Y!!")15W6U>'FO:X-O<(:D<'&T=Q!!&&.F>(2J<G>T,GRW9WRB=X-A<X6U!!!A1&!!!Q!!!!%!!B.F=H*P=C"J<C!I<G]A:8*S<X)J!$"!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!".4:82U;7ZH=SZM>G.M98.T)'FO!'%!]!!-!!-!"!!&!!9!"!!%!!1!"!!(!!1!"!!)!A!!?!!!$1A!!!!!!!!*!!!!$1M!!!!!!!!!!!!!!!!!!!!!!!!)!!!!!!!!!!!!!!!1!!!.!!!!$!!!!!!!!!!!!!!"!!E!!!!!
1
0
@@ -41,7 +42,7 @@
1
1342710272
- -
+
-
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!&N!!!!$!!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!"R!)2:497VF)%:P<'2F=C"4>(*V9X2V=G5`!!!51$$`````#U:P<'2F=C"/97VF!"Z!5!!#!!5!"B-T=G1A='&S>(EA6'6N='RB>'6T!$*!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!"24:82U;7ZH=SZM>G.M98.T)'^V>!!!)%"1!!-!!!!"!!)4:8*S<X)A;7YA+'ZP)'6S=G^S+1!Q1(!!(A!!%B"4:82U;7ZH=SZM>G.M98.T!!!45W6U>'FO:X-O<(:D<'&T=S"J<A"5!0!!$!!$!!1!"Q!)!!1!"!!%!!1!#1!%!!1!#A)!!(A!!!U)!!!!!!!!#1!!!)U,!!!!!!!!!!!!!!!!!!!!!!!!#!!!!!!!!!!!!!!!E!!!!!!"!!M!!!!!
1
0
@@ -50,7 +51,7 @@
1
1074278912
- -
+
-
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!'C!!!!$1!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!#-!]1!!!!!!!!!"#%:P<H1O9X2M!"*!-0````]%2G^O>!!!+1$RRF-RPQ!!!!%.17RJ:WZN:7ZU,G.U<!!41!9!#5&M;7>O<76O>!!F!0(B/TM&!!!!!1V'<WZU)&.J?G5O9X2M!!^!"1!%5WF[:1!!%E"1!!-!"1!'!!=%6'6Y>!!!-E"Q!"Y!!")15W6U>'FO:X-O<(:D<'&T=Q!!&&.F>(2J<G>T,GRW9WRB=X-A<X6U!!!A1&!!!Q!!!!%!!B.F=H*P=C"J<C!I<G]A:8*S<X)J!$"!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!".4:82U;7ZH=SZM>G.M98.T)'FO!&1!]!!-!!-!"!!)!!E!"!!%!!1!"!!+!!1!"!!,!A!!?!!!$1A!!!!!!!!*!!!!D1M!!!!!!!!!!!!!!!!!!!!!!!!)!!!!!!!!!!!!!!#1!!!!!!%!$!!!!!!
-1
0
@@ -59,8 +60,8 @@
1
1352671744
- -
- )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!&(!!!!#Q!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!&%!B$V.I<X=A6'6S<7FO97RT0Q!51#%/5WBP>S"-98FF=F2B9D]!!$*!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!"24:82U;7ZH=SZM>G.M98.T)'^V>!!!"!!!!#"!5!!$!!!!!1!#%W6S=G^S)'FO)#BO<S"F=H*P=CE!-%"Q!"Y!!")15W6U>'FO:X-O<(:D<'&T=Q!!%V.F>(2J<G>T,GRW9WRB=X-A;7Y!6!$Q!!Q!!Q!%!!5!"A!(!!=!"Q!(!!A!"Q!(!!E#!!"Y!!!.#!!!#1!!!!E!!!#.#Q!!!!!!!!!!!!!!!!!!!!!!!!A!!!!!!!!!!!!!!*!!!!!!!1!+!!!!!!
+
-
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!%J!!!!#A!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!&%!B$V.I<X=A6'6S<7FO97RT0Q!%!!!!-E"Q!"Y!!")15W6U>'FO:X-O<(:D<'&T=Q!!&&.F>(2J<G>T,GRW9WRB=X-A<X6U!!!71&!!!Q!!!!%!!ABF=H*P=C"J<A!!-%"Q!"Y!!")15W6U>'FO:X-O<(:D<'&T=Q!!%V.F>(2J<G>T,GRW9WRB=X-A;7Y!6!$Q!!Q!!Q!%!!5!"A!&!!5!"1!&!!=!"1!&!!A#!!"Y!!!.#!!!#1!!!!!!!!#.#Q!!!!!!!!!!!!!!!!!!!!!!!!A!!!!!!!!!!!!!!*!!!!!!!1!*!!!!!!
-1
0
false
@@ -70,7 +71,7 @@
-
-
-
+
-
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!&N!!!!$1!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$*!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!"24:82U;7ZH=SZM>G.M98.T)'^V>!!!)%"1!!-!!!!"!!)4:8*S<X)A;7YA+'ZP)'6S=G^S+1!/1$$`````"%:P<H1!!#.!&A!$"'RF:H1'9W6O>'6S"8*J:WBU!!F"<'FH<GVF<H1!#U!&!!24;8JF!!!31&!!!Q!(!!A!#125:8BU!!!Q1(!!(A!!%B"4:82U;7ZH=SZM>G.M98.T!!!45W6U>'FO:X-O<(:D<'&T=S"J<A"5!0!!$!!$!!1!"!!&!!1!"!!%!!1!"A!%!!I!#Q)!!(A!!!U)!!!!!!!!!!!!!)U,!!!!!!!!!!!!!!!!!!!!!!!!#!!!!!!!!!!)!!!!EA!!!!!"!!Q!!!!!
-1
0
@@ -79,7 +80,7 @@
1
1107821056
- -
+
-
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!%`!!!!#A!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$*!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!"24:82U;7ZH=SZM>G.M98.T)'^V>!!!)%"1!!-!!!!"!!)4:8*S<X)A;7YA+'ZP)'6S=G^S+1!A1#%<476S:W5A>8.F=C"M98FF=H-A<WYA9W^N<7FU!$"!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!".4:82U;7ZH=SZM>G.M98.T)'FO!&1!]!!-!!-!"!!%!!5!"!!%!!1!"!!'!!1!"Q!)!A!!?!!!$1A!!!!!!!!!!!!!D1M!!!!!!!!!!!!!!!!!!!!!!!!)!!!!!!!!!!A!!!#3!!!!!!%!#1!!!!!
-1
0
@@ -88,8 +89,8 @@
1
1342710272
- -
- )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!&(!!!!#Q!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$*!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!"24:82U;7ZH=SZM>G.M98.T)'^V>!!!)%"1!!-!!!!"!!)4:8*S<X)A;7YA+'ZP)'6S=G^S+1!51#%05WBP>S"5:8*N;7ZB<(-`!"2!)1^4;'^X)%RB?76S)&2B9D]!-%"Q!"Y!!")15W6U>'FO:X-O<(:D<'&T=Q!!%V.F>(2J<G>T,GRW9WRB=X-A;7Y!6!$Q!!Q!!Q!%!!1!"1!%!!1!"!!%!!9!"Q!)!!E#!!"Y!!!.#!!!!!!!!!!!!!#.#Q!!!!!!!!!!!!!!!!!!!!!!!!A!!!!)!!!!#!!!!*)!!!!!!1!+!!!!!!
+
-
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!%J!!!!#A!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$*!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!"24:82U;7ZH=SZM>G.M98.T)'^V>!!!&E"1!!-!!!!"!!)):8*S<X)A;7Y!!"2!)1^4;'^X)&2F=GVJ<G&M=T]!-%"Q!"Y!!")15W6U>'FO:X-O<(:D<'&T=Q!!%V.F>(2J<G>T,GRW9WRB=X-A;7Y!6!$Q!!Q!!Q!%!!1!"1!%!!1!"!!%!!9!"Q!%!!A#!!"Y!!!.#!!!!!!!!!!!!!#.#Q!!!!!!!!!!!!!!!!!!!!!!!!A!!!!)!!!!!!!!!*)!!!!!!1!*!!!!!!
-1
0
false
@@ -97,7 +98,7 @@
1
1342710272
- -
+
-
)1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!&N!!!!$!!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!$*!=!!?!!!3%&.F>(2J<G>T,GRW9WRB=X-!!"24:82U;7ZH=SZM>G.M98.T)'^V>!!!)%"1!!-!!!!"!!)4:8*S<X)A;7YA+'ZP)'6S=G^S+1!=1#%75W&N:3"'<WRE:8)A5X2S>7.U>8*F0Q!!&%!Q`````QN'<WRE:8)A4G&N:1!?1&!!!A!(!!A4-X*E)("B=H2Z)&2F<8"M982F=Q!Q1(!!(A!!%B"4:82U;7ZH=SZM>G.M98.T!!!45W6U>'FO:X-O<(:D<'&T=S"J<A"5!0!!$!!$!!1!"!!&!!1!"!!%!!1!"A!%!!E!#A)!!(A!!!U)!!!!!!!!!!!!!)U,!!!!!!!!!!!!!!!!!!!!!!!!#!!!!!!!!!!+!!!!EA!!!!!"!!M!!!!!
-1
0
@@ -107,13 +108,13 @@
1117782528
- -
- )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!"4D!!!!IA!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!"Z!=!!?!!!/$%&O>(-O<(:D<'&T=Q!!"%&O>(-!!#2!=!!?!!!5%E:B;W6E18*S98EO<(:D<'&T=Q!!"5RB?76S!#B!=!!?!!!5%E:B;W6E18*S98EO<(:D<'&T=Q!!#62F<8"M982F=Q!?1(!!(A!!$AR*9W^O,GRW9WRB=X-!!!2*9W^O!!!?1(!!(A!!$QV(<(FQ;#ZM>G.M98.T!!6(<(FQ;!!G1(!!(A!!%B"4:82U;7ZH=SZM>G.M98.T!!!)5W6U>'FO:X-!!#2!=!!?!!!6%V2P<WRT)&"B;7ZU,GRW9WRB=X-!"62P<WRT!$5!]=8'*4Y!!!!"$EF&)%.M98.T:8-O9X2M!"Z!5!!(!!5!"A!(!!A!#1!+!!M&1WRB=X-!&E"Q!!A!!!!)!!!*172E)%RB?76S!"J!=!!)!!!!#!!!$&*F<7^W:3"-98FF=A!!'%"Q!!A!!!!<!!!,4'FO:3!U)(2F?(1!&E"!!!(`````!!]*4'FO:3"5:8BU!#=!]1!!!!!!!!!"#%:P<H1O9X2M!":!-0````])2%Z-8U:P<H1!!#E!]=8JH--!!!!"$5&M;7>O<76O>#ZD>'Q!%U!'!!F"<'FH<GVF<H1!*1$RR:'Q5Q!!!!%.2G^O>#"4;8JF,G.U<!!01!5!"&.J?G5!!!Q!5!!$!"%!%A!4!"Z!=!!)!!%!&!!?!!!/1G^E?3"5:8BU)&.Q:7-!!":!=!!)!!!!(1!!#%2/4&^'<WZU!!!=1(!!#!!!!"M!!!ZH<(FQ;#"Q982I)(.U=A!!)%"Q!!A!!!!<!!!3>'6N='RB>'6T)("B>'AA=X2S!!!%!#%!'%"Q!!A!!1!:!!A!!!B"=H*P>S"6=!!!'E"Q!!A!!1!:!!A!!!J"=H*P>S"%<X>O!!!71(!!#!!!!!)!!!F*23"733"3:79!#!!Q`````Q!;1(!!#!!"!"U!1A!!#U>M?8"I=S"U=G6F!"Z!=!!)!!%!(1"#!!!/6'6N='RB>'6T)(2S:75!!"*!-`````]*4'&Z:8**9W^O!"*!-0````]*4'&Z:8*/97VF!!V!"1!(4X"B9WFU?1!11#%,6GFT;7*J<'FU?4]!$A"1!!1!)!!B!#)!)Q!?1(!!#!!"!#1!(A!!$URB?76S)%FD<WYA6'6Y>!!?1(!!#!!"!#1!(A!!$ERB?76S)&2F<8"M982F!!!71(!!#!!!!!]!!!F$<'FQ9G^B=G1!%5!$!!JJ<7&H:3"U?8"F!!!21!-!#WFN97>F)'2F=(2I!!5!"1!!%E"!!!(`````!#I&;7VB:W5!%E"!!!(`````!#I%<7&T;Q!!"1!(!!!51%!!!@````]!,1:D<WRP=H-!!!N!!A!%<'6G>!!!#5!#!!.U<X!!#U!#!!6S;7>I>!!.1!)!"G*P>(2P<1!!'%"1!!1!,Q!Q!$%!-AF3:7.U97ZH<'5!%A"1!!9!+!!J!#M!,!!O!$-!'E"Q!!A!!1!U!"Y!!!J#6S"J9W^O)'FO!!!=1(!!#!!"!$1!(A!!$5.P<'^S)'FD<WYA;7Y!$U!$!!F49X*P<'RC98)!,!$R!!!!!!!!!!%*4'&Z:8)O9X2M!"J!5!!%!#!!)1!C!#-(4'&Z:8)A-1!M!0%!!!!!!!!!!1F-98FF=CZD>'Q!'E"1!!1!)!!B!#)!)Q>-98FF=C!S!#Q!]1!!!!!!!!!"#5RB?76S,G.U<!!;1&!!"!!A!#%!)A!D"URB?76S)$-!,!$R!!!!!!!!!!%*4'&Z:8)O9X2M!"J!5!!%!#!!)1!C!#-(4'&Z:8)A.!!1!&!!"1!X!$A!/1![!$M!'E"Q!!A!!1!]!"Y!!!N-98FF=C"$<(6T>!!51$$`````#URJ<G5A-3"U:8BU!"2!-0````],4'FO:3!S)(2F?(1!&%!Q`````QN-;7ZF)$-A>'6Y>!!51$$`````#URJ<G5A.#"U:8BU!".!"Q!-4'FO:3!R)'.P<'^S!!!41!=!$%RJ<G5A-C"D<WRP=A!!%U!(!!R-;7ZF)$-A9W^M<X)!!".!"Q!-4'FO:3!U)'.P<'^S!!!=1&!!!Q!2!")!%QZ#<W2Z)&2F?(1A5X"F9Q!!(%!B&E.F<H2F=C"U:8BU)(:F=H2J9W&M<(E!!"2!)1^$98"J>'&M;8JF)&2F?(1!(!"1!!M!0A!`!%!!11"#!%-!2!"&!%9!2Q")!"B!=!!)!!%!31!?!!!*1G^E?3"5:8BU!!Z!-P````]%5'&U;!!!$E!T`````Q6*<7&H:1!11$$`````"E:J<(2F=A!!%E!Q`````QB';7RF4G&N:1!!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$%!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$)!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$-!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$1!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$5!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$9!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$=!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$A!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$E!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%Q!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-4%!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!R-A!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%T!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-41!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!R.1!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%W!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-4=!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!R/!!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%Z!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-D!!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!S-1!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$)S!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-D-!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!S.!!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$)V!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-D9!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!S.Q!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$)Y!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-DE!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!T-!!!2!"1!"]!.Q"0!&!!51"3!&-!6!"6!&9!6Q"9!&E!7A"<!&Q!81"?!&]!9!"B!')!9Q"E!'5!:A"H!'A!;1"K!'M!<!!G1(!!#!!"!'U!(A!!&U2/4&^'=G&N:8>P=GMA6'6N='RB>'6T!"Z!=!!)!!!!'Q!!%&.F98*D;#"5:7VQ<'&U:8-!!"B!=!!)!!!!'Q!!#F2F?(2.98*L:8)!!#E!&Q!%#62F<8"M982F=QF*9W^O)&2F?(1'2WRZ='BT"ERB?76S=Q!!'E"Q!!A!!1"R!$=!!!N597)A1W^O>(*P<!!;1(!!#!!!!"M!!!V4:7&S9WAA2WRZ='BT!"B!=!!)!!!!"Q!!#ERJ<G5A1W^M<X)!!$9!]=4SV7)!!!!"$5>M?8"I4'FT>#ZD>'Q!)%"1!!5!-Q",!%Q!41"/#V"B>'AA*C"*9W^O!"!!1!!#``````````]!>1!=1(!!#!!"!(9!$A!!$52/4&^(<(FQ;(-A7VU!'%"Q!!A!!!!(!!!+2GFM<#"$<WRP=A!!;Q!8!!Q'5'6O9WFM"%RJ<G5(2(*P=("F=A2';7RM#6*F9X2B<G>M:2"';7RM:71A5G6D>'&O:WRF"U6M<'FQ=W5/2GFM<'6E)%6M<'FQ=W5'28*B=W6S"&2F?(1'5W6M:7.U"%VP>G5!!!!51(!!#!!"!(E!3!!!"62P<WRT!"*!=!!)!!!!$Q!!"%FD<WY!!"2!=!!)!!!!$Q!!"V"S:8:J:8=!%E"Q!!A!!!!0!!!%17ZU=Q!!&E"Q!!A!!!!0!!!*6'6S<7FO97RT!":!=!!*$GVF<H5A=G6G:8*F<G.F!!!71(!!#!!!!"M!!!F-98FF=EZB<75!'%"!!!(`````!)!+4'&Z:8*/97VF=Q!!)%"Q!!A!!!!%!!!32WRZ='B-<W&E17ZJ<7&U;7^O!!!C1(!!#!!!!!1!!"65:7VQ<'&U:5RP972"<GFN982J<WY!'E"Q!!A!!!!)!!!.=G6G=G6T;%>M?8"I=Q!?1(!!#!!!!!A!!""S:7:S:8.I6'6N='RB>'6T!!"\!0(.8`%^!!!!!2:3:7:F=G6O9W6T)%.M>8.U:8)O9X2M!&R!5!!H!!U!$A!1!"5!&A!8!"A!'A!<!"Q!(A!@!#5!*A!H!$5!.A!^!%I!<A"P!(!!=A"T!(1!>Q"Y!(I!(A"\!(Q!@1"_!(]!A1##!)-!B!#&!V*F:A!91&!!"!!P!$!!-1!S#%&O>(.3:7.U!!!21!-!#EBP=GF[<WZU97Q!!!^!!Q!)6G6S>'FD97Q!!$U!]1!!!!!!!!!"&%R75'^J<H1T-F2Z='6%:79O9X2M!#"!5!!#!)A!C2&.<X6T:3".<X:F)%.P<X*E=Q!^!0%!!!!!!!!!!22-6F"P;7ZU-T*5?8"F2'6G,G.U<!!A1&!!!A#)!)E247^V=W5A2'^X<C"$<W^S:(-!.Q$R!!!!!!!!!!%54&:1<WFO>$-S6(FQ:52F:CZD>'Q!'E"1!!)!C!#*#F2F<8!A1W^P=G1!!&U!]=4_'^5!!!!"&V.V=("P=H2$<'&T=V^"9X2J<WYO9X2M!$V!&A!%"U2F:G&V<(1/47^W:3"4:7RF9X2J<WY.2WRZ='AA4'FC=G&S?125<W^M!!:"9X2J<WY!!#E!]=6MY>U!!!!"#UF&1W^M<X)O9X2M!"6!"Q!+272H:3"$<WRP=A!!+1$RR7TBX1!!!!%,356$<WRP=CZD>'Q!&5!(!!J';7RM)%.P<'^S!!!11#%,47^V=W5A2'^X<D]!%%!B#U2S97:U)%VP:'5`!"*!-`````]*6'6N=#"*9W^O!"*!)1R$6&*-)&"S:8.T:71!!"2!)1^.<X:F)&.F<'6D>'FP<D]!(%"1!!1!,Q!Q!$%!-AV"<H2T5G6D>#"0=GFH!!Z!-0````]%6'6Y>!!!$%!B"V2.)&.F>$]!'%!B%EVP>8.F)'FO=WFE:3"J9W^O0Q!!&U!(!""5<W^M)#BP<'1A>G&M>75J!!!81!=!%6"F<G.J<#".<X:F)%.P<'^S!"*!)1R4>W&Q)%.P<'^S=T]!!"2!)1Z4;'FG>#"Q=G6T=W6E0Q!!5Q$RR@Q'HA!!!!%15X6Q='^S>%.M98.T,G.U<!![1&!!&!#(!)I!CQ#-!)U!DA#0!*!!E1#3!*-!F!#6!*9!FQ#9!*E!GA#<!*Q(5X6Q='^S>!!O!0(,;5G`!!!!!1N*23"%982B,G.U<!!;1&!!!Q!-!)9!H1B%982B)'^V>!!!)%"1!!-!!!!"!!)4:8*S<X)A;7YA+'ZP)'6S=G^S+1!M!0(,;5G`!!!!!1N*23"%982B,G.U<!!91&!!!Q!-!)9!H1>%982B)'FO!&1!]!!-!!-!"!!%!*Y!"!!%!!1!"!#@!!1!"!#A!Q!!?!!!$1A!!!!!!!!!!!!!$1M!!!!!!!!!!!!!!!!!!!!!!!!+!!!!!!!!!!!!!!!+!!!!!!%!I1!!!!!
+
-
+ )1#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!"4:!!!!IA!-1#%'=X2B>(6T!!!,1!-!"'.P:'5!!""!-0````]'=W^V=G.F!!!71&!!!Q!!!!%!!AFF=H*P=C"P>81!"!!!!"Z!=!!?!!!/$%&O>(-O<(:D<'&T=Q!!"%&O>(-!!#2!=!!?!!!5%E:B;W6E18*S98EO<(:D<'&T=Q!!"5RB?76S!#B!=!!?!!!5%E:B;W6E18*S98EO<(:D<'&T=Q!!#62F<8"M982F=Q!?1(!!(A!!$AR*9W^O,GRW9WRB=X-!!!2*9W^O!!!?1(!!(A!!$QV(<(FQ;#ZM>G.M98.T!!6(<(FQ;!!G1(!!(A!!%B"4:82U;7ZH=SZM>G.M98.T!!!)5W6U>'FO:X-!!#2!=!!?!!!6%V2P<WRT)&"B;7ZU,GRW9WRB=X-!"62P<WRT!$5!]=8'*4Y!!!!"$EF&)%.M98.T:8-O9X2M!"Z!5!!(!!5!"A!(!!A!#1!+!!M&1WRB=X-!&E"Q!!A!!!!)!!!*172E)%RB?76S!"J!=!!)!!!!#!!!$&*F<7^W:3"-98FF=A!!'%"Q!!A!!!!<!!!,4'FO:3!U)(2F?(1!&E"!!!(`````!!]*4'FO:3"5:8BU!#=!]1!!!!!!!!!"#%:P<H1O9X2M!":!-0````])2%Z-8U:P<H1!!#E!]=8JH--!!!!"$5&M;7>O<76O>#ZD>'Q!%U!'!!F"<'FH<GVF<H1!*1$RR:'Q5Q!!!!%.2G^O>#"4;8JF,G.U<!!01!5!"&.J?G5!!!Q!5!!$!"%!%A!4!"Z!=!!)!!%!&!!?!!!/1G^E?3"5:8BU)&.Q:7-!!":!=!!)!!!!(1!!#%2/4&^'<WZU!!!=1(!!#!!!!"M!!!ZH<(FQ;#"Q982I)(.U=A!!)%"Q!!A!!!!<!!!3>'6N='RB>'6T)("B>'AA=X2S!!!%!#%!'%"Q!!A!!1!:!!A!!!B"=H*P>S"6=!!!'E"Q!!A!!1!:!!A!!!J"=H*P>S"%<X>O!!!71(!!#!!!!!)!!!F*23"733"3:79!#!!Q`````Q!;1(!!#!!"!"U!1A!!#U>M?8"I=S"U=G6F!"Z!=!!)!!%!(1"#!!!/6'6N='RB>'6T)(2S:75!!"*!-`````]*4'&Z:8**9W^O!"*!-0````]*4'&Z:8*/97VF!!V!"1!(4X"B9WFU?1!11#%,6GFT;7*J<'FU?4]!$A"1!!1!)!!B!#)!)Q!?1(!!#!!"!#1!(A!!$URB?76S)%FD<WYA6'6Y>!!?1(!!#!!"!#1!(A!!$ERB?76S)&2F<8"M982F!!!71(!!#!!!!!]!!!F$<'FQ9G^B=G1!%5!$!!JJ<7&H:3"U?8"F!!!21!-!#WFN97>F)'2F=(2I!!5!"1!!%E"!!!(`````!#I&;7VB:W5!%E"!!!(`````!#I%<7&T;Q!!"1!(!!!51%!!!@````]!,1:D<WRP=H-!!!N!!A!%<'6G>!!!#5!#!!.U<X!!#U!#!!6S;7>I>!!.1!)!"G*P>(2P<1!!'%"1!!1!,Q!Q!$%!-AF3:7.U97ZH<'5!%A"1!!9!+!!J!#M!,!!O!$-!'E"Q!!A!!1!U!"Y!!!J#6S"J9W^O)'FO!!!=1(!!#!!"!$1!(A!!$5.P<'^S)'FD<WYA;7Y!$U!$!!F49X*P<'RC98)!,!$R!!!!!!!!!!%*4'&Z:8)O9X2M!"J!5!!%!#!!)1!C!#-(4'&Z:8)A-1!M!0%!!!!!!!!!!1F-98FF=CZD>'Q!'E"1!!1!)!!B!#)!)Q>-98FF=C!S!#Q!]1!!!!!!!!!"#5RB?76S,G.U<!!;1&!!"!!A!#%!)A!D"URB?76S)$-!,!$R!!!!!!!!!!%*4'&Z:8)O9X2M!"J!5!!%!#!!)1!C!#-(4'&Z:8)A.!!1!&!!"1!X!$A!/1![!$M!'E"Q!!A!!1!]!"Y!!!N-98FF=C"$<(6T>!!51$$`````#URJ<G5A-3"U:8BU!"2!-0````],4'FO:3!S)(2F?(1!&%!Q`````QN-;7ZF)$-A>'6Y>!!51$$`````#URJ<G5A.#"U:8BU!".!"Q!-4'FO:3!R)'.P<'^S!!!41!=!$%RJ<G5A-C"D<WRP=A!!%U!(!!R-;7ZF)$-A9W^M<X)!!".!"Q!-4'FO:3!U)'.P<'^S!!!=1&!!!Q!2!")!%QZ#<W2Z)&2F?(1A5X"F9Q!!(%!B&E.F<H2F=C"U:8BU)(:F=H2J9W&M<(E!!"2!)1^$98"J>'&M;8JF)&2F?(1!(!"1!!M!0A!`!%!!11"#!%-!2!"&!%9!2Q")!"B!=!!)!!%!31!?!!!*1G^E?3"5:8BU!!Z!-P````]%5'&U;!!!$E!T`````Q6*<7&H:1!11$$`````"E:J<(2F=A!!%E!Q`````QB';7RF4G&N:1!!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$%!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$)!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$-!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$1!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$5!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$9!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$=!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$A!.A$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!)E"1!!5!-Q",!%Q!41"/$6"B>'AA*C"*9W^O)$E!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%Q!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-4%!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!R-A!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%T!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-41!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!R.1!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%W!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-4=!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!R/!!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$%Z!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-D!!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!S-1!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$)S!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-D-!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!S.!!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$)V!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-D9!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!S.Q!!/!$R!!!!!!!!!!%,2X*B='BJ9SZD>'Q!*%"1!!5!-Q",!%Q!41"/$F"B>'AA*C"*9W^O)$)Y!!!Y!0%!!!!!!!!!!1N(=G&Q;'FD,G.U<!!E1&!!"1!T!%M!4!".!%Y/5'&U;#!G)%FD<WYA-DE!!$A!]1!!!!!!!!!"#U>S98"I;7-O9X2M!#2!5!!&!$-!3Q"-!%U!4AZ1982I)#9A37.P<C!T-!!!2!"1!"]!.Q"0!&!!51"3!&-!6!"6!&9!6Q"9!&E!7A"<!&Q!81"?!&]!9!"B!')!9Q"E!'5!:A"H!'A!;1"K!'M!<!!G1(!!#!!"!'U!(A!!&U2/4&^'=G&N:8>P=GMA6'6N='RB>'6T!"Z!=!!)!!!!'Q!!%&.F98*D;#"5:7VQ<'&U:8-!!"B!=!!)!!!!'Q!!#F2F?(2.98*L:8)!!#E!&Q!%#62F<8"M982F=QF*9W^O)&2F?(1'2WRZ='BT"ERB?76S=Q!!'E"Q!!A!!1"R!$=!!!N597)A1W^O>(*P<!!;1(!!#!!!!"M!!!V4:7&S9WAA2WRZ='BT!"B!=!!)!!!!"Q!!#ERJ<G5A1W^M<X)!!$9!]=4SV7)!!!!"$5>M?8"I4'FT>#ZD>'Q!)%"1!!5!-Q",!%Q!41"/#V"B>'AA*C"*9W^O!"!!1!!#``````````]!>1!=1(!!#!!"!(9!$A!!$52/4&^(<(FQ;(-A7VU!'%"Q!!A!!!!(!!!+2GFM<#"$<WRP=A!!;Q!8!!Q'5'6O9WFM"%RJ<G5(2(*P=("F=A2';7RM#6*F9X2B<G>M:2"';7RM:71A5G6D>'&O:WRF"U6M<'FQ=W5/2GFM<'6E)%6M<'FQ=W5'28*B=W6S"&2F?(1'5W6M:7.U"%VP>G5!!!!51(!!#!!"!(E!3!!!"62P<WRT!"*!=!!)!!!!$Q!!"%FD<WY!!"2!=!!)!!!!$Q!!"V"S:8:J:8=!%E"Q!!A!!!!0!!!%17ZU=Q!!&E"Q!!A!!!!0!!!*6'6S<7FO97RT!":!=!!*$GVF<H5A=G6G:8*F<G.F!!!71(!!#!!!!"M!!!F-98FF=EZB<75!'%"!!!(`````!)!+4'&Z:8*/97VF=Q!!)%"Q!!A!!!!%!!!32WRZ='B-<W&E17ZJ<7&U;7^O!!!C1(!!#!!!!!1!!"65:7VQ<'&U:5RP972"<GFN982J<WY!'E"Q!!A!!!!)!!!.=G6G=G6T;%>M?8"I=Q!?1(!!#!!!!!A!!""S:7:S:8.I6'6N='RB>'6T!!"\!0(.8`%^!!!!!2:3:7:F=G6O9W6T)%.M>8.U:8)O9X2M!&R!5!!H!!U!$A!1!"5!&A!8!"A!'A!<!"Q!(A!@!#5!*A!H!$5!.A!^!%I!<A"P!(!!=A"T!(1!>Q"Y!(I!(A"\!(Q!@1"_!(]!A1##!)-!B!#&!V*F:A!91&!!"!!P!$!!-1!S#%&O>(.3:7.U!!!21!-!#EBP=GF[<WZU97Q!!!^!!Q!)6G6S>'FD97Q!!$U!]1!!!!!!!!!"&%R75'^J<H1T-F2Z='6%:79O9X2M!#"!5!!#!)A!C2&.<X6T:3".<X:F)%.P<X*E=Q!^!0%!!!!!!!!!!22-6F"P;7ZU-T*5?8"F2'6G,G.U<!!A1&!!!A#)!)E247^V=W5A2'^X<C"$<W^S:(-!.Q$R!!!!!!!!!!%54&:1<WFO>$-S6(FQ:52F:CZD>'Q!'E"1!!)!C!#*#F2F<8!A1W^P=G1!!&U!]=4_'^5!!!!"&V.V=("P=H2$<'&T=V^"9X2J<WYO9X2M!$V!&A!%"U2F:G&V<(1/47^W:3"4:7RF9X2J<WY.2WRZ='AA4'FC=G&S?125<W^M!!:"9X2J<WY!!#E!]=6MY>U!!!!"#UF&1W^M<X)O9X2M!"6!"Q!+272H:3"$<WRP=A!!+1$RR7TBX1!!!!%,356$<WRP=CZD>'Q!&5!(!!J';7RM)%.P<'^S!!!11#%,47^V=W5A2'^X<D]!%%!B#U2S97:U)%VP:'5`!"*!-`````]*6'6N=#"*9W^O!"*!)1R$6&*-)&"S:8.T:71!!"2!)1^.<X:F)&.F<'6D>'FP<D]!(%"1!!1!,Q!Q!$%!-AV"<H2T5G6D>#"0=GFH!!Z!-0````]%6'6Y>!!!$%!B"V2.)&.F>$]!'%!B%EVP>8.F)'FO=WFE:3"J9W^O0Q!!&U!(!""5<W^M)#BP<'1A>G&M>75J!!!81!=!%6"F<G.J<#".<X:F)%.P<'^S!"*!)1R4>W&Q)%.P<'^S=T]!!"2!)1Z4;'FG>#"Q=G6T=W6E0Q!!5Q$RR@Q'HA!!!!%15X6Q='^S>%.M98.T,G.U<!![1&!!&!#(!)I!CQ#-!)U!DA#0!*!!E1#3!*-!F!#6!*9!FQ#9!*E!GA#<!*Q(5X6Q='^S>!!O!0(,;5G`!!!!!1N*23"%982B,G.U<!!;1&!!!Q!-!)9!H1B%982B)'^V>!!!&E"1!!-!!!!"!!)):8*S<X)A;7Y!!#Q!]=NJ3<]!!!!"#UF&)%2B>'%O9X2M!"B!5!!$!!Q!BA#>"U2B>'%A;7Y!6!$Q!!Q!!Q!%!!1!HA!%!!1!"!!%!*]!"!!%!+!$!!"Y!!!.#!!!!!!!!!!!!!!.#Q!!!!!!!!!!!!!!!!!!!!!!!!I!!!!!!!!!!!!!!!I!!!!!!1#B!!!!!!
1
0
true
1
1
- 1082143248
+ 1342710288
diff --git a/resource/plugins/NIIconEditor/Controls/INI.ctl b/resource/plugins/NIIconEditor/Controls/INI.ctl
index 1bde0a81..69e4b886 100644
Binary files a/resource/plugins/NIIconEditor/Controls/INI.ctl and b/resource/plugins/NIIconEditor/Controls/INI.ctl differ
diff --git a/resource/plugins/NIIconEditor/Controls/Settings.ctl b/resource/plugins/NIIconEditor/Controls/Settings.ctl
index 0ce59ef7..342b6ed6 100644
Binary files a/resource/plugins/NIIconEditor/Controls/Settings.ctl and b/resource/plugins/NIIconEditor/Controls/Settings.ctl differ
diff --git a/resource/plugins/NIIconEditor/Miscellaneous/Icon Editor/MenuSelection(User).vi b/resource/plugins/NIIconEditor/Miscellaneous/Icon Editor/MenuSelection(User).vi
index ce559149..9a490539 100644
Binary files a/resource/plugins/NIIconEditor/Miscellaneous/Icon Editor/MenuSelection(User).vi and b/resource/plugins/NIIconEditor/Miscellaneous/Icon Editor/MenuSelection(User).vi differ
diff --git a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Load.vi b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Load.vi
index 4d6d0a59..08c4947a 100644
Binary files a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Load.vi and b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Load.vi differ
diff --git a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/ReadDataFromLabVIEWINI.vi b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/ReadDataFromLabVIEWINI.vi
index 845ec7c4..c3ae4995 100644
Binary files a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/ReadDataFromLabVIEWINI.vi and b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/ReadDataFromLabVIEWINI.vi differ
diff --git a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Write INI Tokens and VI Tags.vi b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Write INI Tokens and VI Tags.vi
index 9ff37138..61ff3844 100644
Binary files a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Write INI Tokens and VI Tags.vi and b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/Write INI Tokens and VI Tags.vi differ
diff --git a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/WriteDataToLabVIEWINI.vi b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/WriteDataToLabVIEWINI.vi
index bb28064b..2a9dbd14 100644
Binary files a/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/WriteDataToLabVIEWINI.vi and b/resource/plugins/NIIconEditor/Miscellaneous/Load Unload/WriteDataToLabVIEWINI.vi differ
diff --git a/resource/plugins/NIIconEditor/Miscellaneous/Menubar/ShowLayersPalette.vi b/resource/plugins/NIIconEditor/Miscellaneous/Menubar/ShowLayersPalette.vi
deleted file mode 100644
index cbe79e66..00000000
Binary files a/resource/plugins/NIIconEditor/Miscellaneous/Menubar/ShowLayersPalette.vi and /dev/null differ
diff --git a/resource/plugins/NIIconEditor/Support/lv_icon.rtm b/resource/plugins/NIIconEditor/Support/lv_icon.rtm
index d1cb996f..294d29eb 100644
Binary files a/resource/plugins/NIIconEditor/Support/lv_icon.rtm and b/resource/plugins/NIIconEditor/Support/lv_icon.rtm differ
diff --git a/resource/plugins/lv_icon.vi b/resource/plugins/lv_icon.vi
index ecd80799..14ce9c84 100644
Binary files a/resource/plugins/lv_icon.vi and b/resource/plugins/lv_icon.vi differ
diff --git a/vi.lib/LabVIEW Icon API/Set Text Icon/Qualify Library Icon Core.vi b/vi.lib/LabVIEW Icon API/Set Text Icon/Qualify Library Icon Core.vi
index 85444b5d..96994d2f 100644
Binary files a/vi.lib/LabVIEW Icon API/Set Text Icon/Qualify Library Icon Core.vi and b/vi.lib/LabVIEW Icon API/Set Text Icon/Qualify Library Icon Core.vi differ
diff --git a/vi.lib/LabVIEW Icon API/Set Text Icon/Text-Based VI Icon.lvlib b/vi.lib/LabVIEW Icon API/Set Text Icon/Text-Based VI Icon.lvlib
index 434bf3f7..fbcecf69 100644
--- a/vi.lib/LabVIEW Icon API/Set Text Icon/Text-Based VI Icon.lvlib
+++ b/vi.lib/LabVIEW Icon API/Set Text Icon/Text-Based VI Icon.lvlib
@@ -8,7 +8,7 @@
-
-
+
-
4