Spent a few days learning how to program more in-depth with the macro language available in HostAccess from “Rogue Wave” software. A few notes:
- “Sculpting” means creating an overlay for the host interface and making it more GUI-like. On top of sculpting the interface you can also use AiF (Applications interface Facility) controls to create input boxes, clickable buttons and other controls.
- The PASSKEYS function can only be returned from or broken out of by hitting the “Enter” key on the keyboard. This must be the main “Enter” key and not the “Enter” key that is nested with the Number Pad on keyboards (in the far-right corner of the keyboard usually) The problem that I ran into with this is that in the macro I was working on I needed to allow the user to arrow up or down to select a particular field to apply the results of the pop-up list box that would appear when they pressed “Enter” to return from the PASSKEYS function. But when they would press “Enter” it would create a carriage return (CR) response to the host and would move the field down one line. Then the choice they made from the pop-up list box would get applied to the wrong field (the one beneath the one they actually pressed “Enter” on). I worked with Dean Napper with Rogue Wave support to see if there is a way around this. He actually remotely viewed what I was doing and so I was able to show him my dilemma. He is going to get with their engineers and see about updating the code to allow for suppression of the CR associated with the PASSKEYS function. As a work-around he looked into using global variables which will allow me to save information to a variable that will survive between macro instances. So I can run the macro for the first part, get some information and save it to a global variable, and then run the same macro again and use conditional statements based on the global variable to allow execution to run from a different point in the macro. This will be a workaround for the shortcoming of the PASSKEYS function since it will allow the user to select the number and then just run the macro again when they are on the right field and it won’t send a CR so it won’t move down to the wrong line.
- You can “Raise an event” for controls that you create using ESC sequences. One thing to look out for is that based on the event, different data is returned. For the following examples the syntax is as follows:
<”XXX”> => Things surrounded by <> indicate system control things. IE:
=> Carriage Return. id => Control id of the control associated with the event. (Whatever you choose to name the control you created)
event => Event number. (1-13 defined) ie: 1-> Enter pressed, 2-> ESCape pressed, 3-> Button clicked, etc..
argument => Some events send additional information as arguments.
- Double-click event -> Returns <stx>WC<cr>id,event{,argument}<cr>. So, here is where the problem was for me that took a while for me to understand. I had a conditional statement that was checking the value of the event string that was being returned from the control. I had it checking only for the “id,event” because that is what is returned when “Enter” (Event number 1) or “ESCape” (Event number 2) are triggered. It does not return any additional arguments. But Double-clicking (Event number 7) does return an additional argument -> the entire host string associated with the item selected in the list-box. So when I would say
IF DATA2 = "choice2,7"that part of the code would never execute because it wasn’t equal to that. Instead it was equal to “choice2,7,*’d’ CR ‘x’ CR ‘y’ CR … etc (whatever the whole string for the item happened to be)” So, I needed to use a function likeDATA3 = mid$(DATA2,9to choose a certain portion only of the returned string (like just the first 9 characters so that the value would only be “choice2,7″ like it was expecting)
- Double-click event -> Returns <stx>WC<cr>id,event{,argument}<cr>. So, here is where the problem was for me that took a while for me to understand. I had a conditional statement that was checking the value of the event string that was being returned from the control. I had it checking only for the “id,event” because that is what is returned when “Enter” (Event number 1) or “ESCape” (Event number 2) are triggered. It does not return any additional arguments. But Double-clicking (Event number 7) does return an additional argument -> the entire host string associated with the item selected in the list-box. So when I would say
- VERY IMPORTANT NOTE: If you are running an “IF THEN ELSE” statement checking a variable that is returned from a list box, then you MUST run it through a function like Mid$(string,4,4) in order to strip the first hidden characters (<stx> or WC maybe.. not quite sure.. but it is proceeded by 2 characters, so must be the WC -> in other words: add 2 to the first argument =>(string,4,4) to move it past the hidden characters and then grab the part of the string that you want to run the conditional statement against.)