Perhaps one day you would like it to ship on multiple platforms. Perhaps one day we’ll write that book too. Meanwhile, Microsoft Windows.
You will however find that whenever possible we keep the code platform independent. If we use platform-dependent utilities we mention it and explain why; we might also mention alternatives available on other platforms.
-
APLTree is the name of an open-source library that offers robust, tested and well documented solutions to many everyday problems you face when addressing the tasks discussed in this book.
We will use this library extensively and discuss it in detail. More at the source: https://aplteam.github.io/apltree. You can also search for “apltree” on GitHub.
+
APLTree is the name of an open-source library that offers robust, tested and well documented solutions to many everyday problems you face when addressing the tasks discussed in this book.
These days seasoned programmers often have strong opinions about whether to use an object-oriented approach or a functional approach, or to mix them both.
We have seen friendships broken on these issues. In this book we take a mixed approach.
The APLTree library is an open-source project hosted on GitHub. It offers solutions for many every-day problems a Dyalog APL programmer might run into. In the Cookbook we will use many of its members. For details see https://aplteam.github.io/apltree.
+
The APLTree library is an open-source project hosted on GitHub. It offers solutions for many every-day problems a Dyalog APL programmer might run into. In the Cookbook we will use many of its members. For details see https://github.com/aplteam/apltree/wiki.
In a runtime interpreter or an EXE, there is no APL session, and output to the session which would have been visible in a development system will simply disappear. If we want to see this output, we need to write it to a log file.
-
But how do we find out where we need to make changes? We recommend you think about this from the start, and ensure that all intentional output goes through a log function, or at least use an explicit ⎕← so that output can easily be identified in the source.
+
In a runtime interpreter or an EXE, there is no APL session, and output to the session which would have been visible in a development system will simply disappear.
+
+
+
+
+
Note that output assigned to ⎕ or ⍞ does not stop the runtime executable.
+
However, when the result of a function is neither consumed by another function nor assigned to a variable then you will see the message “This Dyalog APL runtime application has attempted to use the APL session and therefore be closed.”, and that will be the end of it.
+
+
+
+
If we want to see this output, we need to write it to a log file. But how do we find out where we need to make changes? We recommend you think about this from the start, and ensure that all intentional output goes through a log function, or at least use an explicit ⎕← so that output can easily be identified in the source.
In a more complex application than ours you might prefer a different approach. Using an INI file for this is not a bad idea: it gives you scope to define more than just the modules to be loaded, and some code to execute.
-
Also, if you have not one butseveral applications to support, it is useful to implement your own generalised user command like ]runmake.
+
Also, if you have not one but several applications to support, it is useful to implement your own generalised user command like ]runmake.
Execute, Tester and Tests have no place in the finished application, nor do we need the test helpers either.
Export automates what we’ve done so far by calling the Export command from the File menu. If the Bind method fails, it retries up to 50 times before giving up.
From experience we know that, with the OS, the machine, the network, the filesystem and who knows what else, the command can fail several times before finally succeeding.
+
+
+
+
Why is there a “ProductVersion” and a “FileVersion”? No idea! On Stack Overflow this was discussed more than once, and it seems that there are very few cases were it might make sense to have them not in sync.
+
But “FileVersion” is the more important one: the Inno installer for example (see chapter 16 “Creating SetUp.exe”) compares the “FileVersion” of an already installed version with the possibly new version, and if they are not different then it won't overwrite the EXE - you don't want that!
+
+
+
-
The Bind method
+
The Bind method
Note that for the Bind method to work as discussed in this chapter you must use at least version 16.0.31811.0 of Dyalog. Before that Bind was not an official method and did not support the details.
Users expect applications to provide help in one way or another. One option is to provide the help as a hypertext system. Under Windows, CHM files are the standard way to provide such help. There are powerful applications available that can assist you in providing help; HelpAndManual [1] is just an example.
-
However, we take a different approach here: rather than using any third-party software we use Markdown2Help from the APLTree library. That allows us to create a help system that:
+
However, we take a different approach here: rather than using any third-party software we use Markdown2Help from the APL_cation [2] project. That allows us to create a help system that:
If for some reason you’ve created MyApp.exe by binding the application to the development version of Dyalog rather than the runtime (you can do this by providing a 0 as left argument to the MakeExport function) then you might run into a problem. Our code notices whether it is running under a development EXE or a runtime EXE. Error trapping will be inactive (unless it is enforced via the INI) and ⎕OFF won’t be executed; instead it would execute → and hang around but without you being able to see the session.
-
So don’t do this. Because you have Ride, the development version has no advantages over the runtime EXE anyway.
+
So don’t do this. Because you have Ride at your disposal the development version has no advantages over the runtime EXE anyway.
Inno comes with a built-in script language that allows you to do pretty much whatever you like. However, scripting is beyond the scope of this chapter.
When an EXE is part of the installation Inno compares the “FileVersion” of what's already installed with the one that is about to be installed. It they match Inno won't take any action. That means that if you forget to set the “FileVersion” (see chapter 10: “Make: Export”) when creating the stand-alone EXE then it will always be 0.0.0.0, so they won't ever differ, and the first installed EXE will never be replaced!
A problem like the aforementioned one won't cause an error message; you just don't get the new EXE installed. Assuming that you have been careful enough to realize that there is a problem, how to get to the bottom of it?
+
If the installer does not behave as expected add /LOG={filename} to it. Then Inno will report all actions and even conclusions to that file.
+
In the above scenario you would find something similiar to this in the log file:
+
2018-05-08 06:26:30.826 -- File entry --
+2018-05-08 06:26:30.827 Dest filename: C:\Program Files (x86)\..\Foo.exe
+2018-05-08 06:26:30.827 Time stamp of our file: 2018-05-07 13:07:26.000
+2018-05-08 06:26:30.827 Dest file exists.
+2018-05-08 06:26:30.827 Time stamp of existing file: 2018-05-07 12:51:24.000
+2018-05-08 06:26:30.827 Version of our file: 0.0.0.0
+2018-05-08 06:26:30.832 Version of existing file: 0.0.0.0
+2018-05-08 06:26:30.832 Same version. Skipping.
