Small fix in PDFHummus to Virtualstore directory. Found a link to detect Microsoft's read write redirect.

PDFHummus-minGW-tools/README.txt

@@ -36,4 +36,9 @@
    14 April 2020
       Talked about cleaning up the README as well as rebuilding PDFHummus as a statically linked library "on my own". We will try and do this in a couple more sessions, so Wesley 
       can rest his small brain. :D
-      
+   19 May 2020
+   Per Raymond Chen - "UAC Virtualization kicks in for applications which were designed for versions of Windows prior to Windows Vista. 
+   These applications often assume that they are running with administrative privileges, and when they try to write to file or registry locations 
+   that are normally restricted to administrators, they expect them to succeed. So UAC Virtualization lets those writes succeed by secretly redirecting 
+   them to another location inside the user profile. The reverse happens when the application later tries to read the file or registry key: If the file or 
+   key exists in the redirected location, it is used instead of the one in the administrative location." - Msft CTO

ToDo/ToDo.txt

@@ -5,4 +5,16 @@ turn that on and off, manually. This may lead to another task of addding this to
 
 2May20
 1) Continue with PDF Hummus, get text and image to work on same page using the Shutdown & Continue function.
-2) make the text on page code into one function vs all the separate parts it is in currently.
+2) make the text on page code into one function vs all the separate parts it is in currently.
+
+5May20
+1) When using modifyPage we found a segment fault - line 104. - will need to figure that out next time.
+2) pdfWriter can be used with multiple pdfPage(s) - we don't seem to need shutdown and continue to get mutliple different pages launched.
+
+19May20
+1) in ..\PDFHummus-minGW-tools\Readme.txt there are notes describing why Msft implemented the VirtualStore, unfortunately there is unpredictable behavior.
+Some people at StackOverFLOW have a suggestion on how to deal with it.
+Microsoft does not gurantee that a file will be written and be able to be read. To undo this and figure out where a file is being written/read
+the link below may have a possible solution. Since Msft writes files "randomly", when trying to read or modify the same file the program is unable
+to access the file. The below link will potentially help in detection of Msft's read write redirect (Msft claims that they do it both directions...). 
+https://stackoverflow.com/questions/14005081/how-to-detect-file-redirection-to-the-windows-virtualstore 

pdfHummusTest1.cpp

@@ -22,8 +22,8 @@
 #include "AbstractContentContext.h"
 int main(){
     //  
-    //  Go to: "%AppData%\..\Local\VirtualStore"  - because Windows does not write to the C:\ drive  
-    printf("if running on Windows check here for file(s): %%AppData%%\\..\\Local\\VirtualStore\n");
+    //  Go to: "%LOCALAPPDATA%\VirtualStore"  - because Windows does not write to the C:\ drive  
+    printf("if running on Windows check here for file(s): %%LOCALAPPDATA%%\\VirtualStore\n");
     PDFWriter pdfWriter;
     //  PREPARE PDF DOCUMENT
     //  ********************