Some improvemnts

5jt · Jan 1, 2019 · 508048d · 508048d
1 parent 4ba67c2
commit 508048d
Show file tree

Hide file tree

Showing 6 changed files with 43 additions and 118 deletions.
diff --git a/HTML/03-Packaging.html b/HTML/03-Packaging.html
diff --git a/HTML/16-Creating-SetUp.exe.html b/HTML/16-Creating-SetUp.exe.html
@@ -1,5 +1,5 @@
 <!DOCTYPE html>
-<html lang="en">
+<html lang="en" style="scroll-behavior:smooth" >
 <head>
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
 <meta charset="utf-8">
@@ -97,15 +97,7 @@ <h2>Considerations</h2>
 </a>
 </div>
 <p>An installer needs admin rights. Installing a program is a potentially dangerous thing.</p>
-
-<div class="leanpub">
-<img src="https://download.aplwiki.com/LeanPub/Images/information.png" alt="Information">
-<div>
-<p>It is rare these days to install an application in, say, <code>C:\MyFolder</code>. Under such rare circumstances, it might be possible to install an application without admin rights.</p>
-<p>However, even installing a font requires admin rights.</p>
-</div>
-</div>
-
+<p>I&gt; It is rare these days to install an application in, say, <code>C:\MyFolder</code>. Under such rare circumstances, it might be possible to install an application without admin rights. I&gt; I&gt; However, even installing a font requires admin rights.</p>
 <p>Programs are usually installed in one of:</p>
 <ul>
 <li><code>C:\Program Files</code></li>
@@ -125,13 +117,7 @@ <h2>Considerations</h2>
 <li><code>C:\Users\{username}\AppData\Roaming</code></li>
 </ul>
 <p>The <code>Roaming</code> folder is the right choice if a user wants the application to be available regardless of which computer she logs on to.</p>
-
-<div class="leanpub_A">
-<h3>About C:\ProgramData</h3>
-<p>There is only one difference between the <em>AppData</em> and the <em>ProgramData</em> folders: every user has her own <em>AppData</em> folder but there is only a single <em>ProgramData</em> folder, shared by all users.</p>
-<p>The folder <code>C:\ProgramData</code> is hidden by default, so you will see it only when you tick the <em>Hidden items</em> checkbox on the <em>View</em> tab of the Windows Explorer.</p>
-</div>
-
+<p>A&gt; # About C:\ProgramData A&gt; There is only one difference between the <em>AppData</em> and the <em>ProgramData</em> folders: every user has her own <em>AppData</em> folder but there is only a single <em>ProgramData</em> folder, shared by all users. A&gt; A&gt; The folder <code>C:\ProgramData</code> is hidden by default, so you will see it only when you tick the <em>Hidden items</em> checkbox on the <em>View</em> tab of the Windows Explorer.</p>
 <p>Of course you can put that folder in any place you want — provided you have the necessary rights — but by choosing one of these two locations you stick to what's usual under Windows.</p>
 <div class="h_tag">
 <a href="#Sample-application" id="Sample-application" class="autoheader_anchor">
@@ -240,7 +226,7 @@ <h3>The section [Setup]</h3>
 <p>The meaning of much of the above is pretty obvious. All those names <em>must</em> be defined, however: Inno needs them.</p>
 <p>Notes:</p>
 <ul>
-<li>The variables defined at the top of the Inno script (before the first section) are dereferenced here as <code>{#varsname}</code>.</li>
+<li>The variables defined at the top of the Inno script (before the first section) are referenced here as <code>{#varsname}</code>.</li>
 <li>The <code>AppId</code> is used to identify an application, in particular for un-installing it. It can be anything as long as it is less than 128 characters long but using a GUID[<a href="#fnref2" class="footnote_link"><sup>2</sup></a>] is a good idea. Tip: don't add a version number to it.
 <p>You can create a GUID from within Inno Script Studio: check the <em>Tools &gt; Generate GUID</em> menu item.</p></li>
 <li><code>pf32</code> is an internal Inno constant. It points to the machine's 32-bit program folder, by default <code>C:\Program folder (x86)</code>.
@@ -315,14 +301,7 @@ <h3>The section [Dirs]</h3>
 <p>With the above line we tell Inno to create a folder <code>{#MyAppName}</code> which in our case will be “My Company Ltd”. Note that <code>commonappdata</code> defaults to <code>ProgramData\</code>, usually on the <code>C:\</code> drive.</p>
 <p>Instead we could have used <code>localappdata</code>, which defaults to <code>C:\Users\{username}\AppData\Local</code>. There are many more constants available; refer to <em>Constants</em> in the Inno Help for details.</p>
 <p>We also tell Inno to give any user in the <code>Users</code> group the right to modify files in this directory.</p>
-
-<div class="leanpub">
-<img src="https://download.aplwiki.com/LeanPub/Images/warning.png" alt="Warning">
-<div>
-<p>Of course you must not grant Modify rights to the folder where your application's <abbr title="Executable file with the extension 'exe'">EXE</abbr> lives, let alone to folders not associated with your application.</p>
-</div>
-</div>
-
+<p>W&gt; Of course you must not grant Modify rights to the folder where your application's <abbr title="Executable file with the extension 'exe'">EXE</abbr> lives, let alone to folders not associated with your application.</p>
 <p>Note that if you install the application <em>again</em> the folder <em>won't</em> be created – and you won't see an error message either.</p>
 <div class="h_tag">
 <a href="#files" id="files" class="autoheader_anchor">
@@ -355,14 +334,7 @@ <h3>The section [Files]</h3>
 <li>We include the font <code>APL385 Unicode</code> if it does not already exist (<code>onlyifdoesntexist</code>) and we ensure the font is not uninstalled, even if the application is (<code>uninsneveruninstall</code>).</li>
 <li>If you want to Ride into your application you also need the Conga DLLs. Usually this would be done only while the application is still under development or being tested.</li>
 </ul>
-<div class="leanpub">
-<img src="https://download.aplwiki.com/LeanPub/Images/warning.png" alt="Warning">
-<div>
-<h3>.NET</h3>
-<p>If your applications call any .NET methods make sure you include the Dyalog .NET bridge files!</p>
-</div>
-</div>
-
+<p>W&gt; # .NET W&gt; W&gt; If your applications call any .NET methods make sure you include the Dyalog .NET bridge files!</p>
 <div class="h_tag">
 <a href="#icons" id="icons" class="autoheader_anchor">
 <h3>The section [Icons]</h3>

diff --git a/HTML/Appendix-06_The current directory.html b/HTML/Appendix-06_The current directory.html
@@ -1,5 +1,5 @@
 <!DOCTYPE html>
-<html lang="en">
+<html lang="en" style="scroll-behavior:smooth" >
 <head>
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
 <meta charset="utf-8">
@@ -64,6 +64,13 @@ <h2>Remarks</h2>
 </div>
 <p>Normally when a program is started the folder the EXE lives in determines the current directory.</p>
 <p>This is also true when you call any Dyalog EXE. However, from an APL programmer's point of view the workspace defines the program, not the EXE. That's why we advocate changing the current directory to where the workspace was loaded from.</p>
+<table style="font-size:xx-large;color:red;">
+<tbody>
+<tr>
+<td>⍝TODO⍝ This is currently not true:</td>
+</tr>
+</tbody>
+</table>
 <p>It's similar for DYAPPs, though they don't load a workspace but assemble it dynamically. In case of a double-click on a DYAPP luckily there is no need to do anything because the current directory will be the folder the DYAPP lives in, which is exactly how it should be.</p>
 <table style="font-size:xx-large;color:red;">
 <tbody>

diff --git a/manuscript/03-Packaging.md b/manuscript/03-Packaging.md
@@ -177,7 +177,13 @@ You should see a message: _File Z:\\code\\v03\\MyApp.exe successfully created._
 
 If it keeps failing then the by far most common reason is that the EXE is running – you cannot replace an EXE while it is running. 
 
-I> Although you cannot replace a running EXE what you _can_ do is to rename it; that is possible. You can then create a new EXE with the original name.
+I> Although you cannot replace a running EXE what you _can_ do is to rename it. You can then create a new EXE with the original name.
+
+A> ### The "Command line" field
+A> You might think that when you specify something in the "Command line" field (like `name="APL"`) this would become available via a `2 ⎕NQ'.' 'GetCommandLineArgs'` statement but that would not work.
+A> The reason is that `2 ⎕NQ'.' 'GetCommandLineArgs'` gives you the command line _of the EXE_ when it is called.
+A>
+A> However, you can get the value with `2 ⎕NQ'.' 'GetEnvironment' 'name'`.
 
 In case you wonder what a “Console application” is: 
 

diff --git a/manuscript/16-Creating-SetUp.exe.md b/manuscript/16-Creating-SetUp.exe.md
@@ -221,7 +221,7 @@ All those names _must_ be defined, however: Inno needs them.
 
 Notes:
 
-* The variables defined at the top of the Inno script (before the first section) are dereferenced here as `{#varsname}`.
+* The variables defined at the top of the Inno script (before the first section) are referenced here as `{#varsname}`.
 
 * The `AppId` is used to identify an application, in particular for un-installing it. It can be anything as long as it is less than 128 characters long but using a GUID[^guid] is a good idea. Tip: don't add a version number to it.
 

diff --git a/manuscript/Appendix-06_The current directory.md b/manuscript/Appendix-06_The current directory.md
@@ -44,6 +44,8 @@ Normally when a program is started the folder the EXE lives in determines the cu
 
 This is also true when you call any Dyalog EXE. However, from an APL programmer's point of view the workspace defines the program, not the EXE. That's why we advocate changing the current directory to where the workspace was loaded from.
 
+|⍝TODO⍝ This is currently not true: |{style="font-size:xx-large;color:red;"}
+
 It's similar for DYAPPs, though they don't load a workspace but assemble it dynamically. In case of a double-click on a DYAPP luckily there is no need to do anything because the current directory will be the folder the DYAPP lives in, which is exactly how it should be.
 
 |⍝TODO⍝: we need a mechanism for DYAPPs in case they got called programmitically!|{style="font-size:xx-large;color:red;"}
-Original file line number
+Diff line change
@@ Expand Up @@
     Notes:
-    * The variables defined at the top of the Inno script (before the first section) are dereferenced here as `{#varsname}`.
+    * The variables defined at the top of the Inno script (before the first section) are referenced here as `{#varsname}`.
     * The `AppId` is used to identify an application, in particular for un-installing it. It can be anything as long as it is less than 128 characters long but using a GUID[^guid] is a good idea. Tip: don't add a version number to it.
@@ Expand Down @@