In this section, we are going to discuss
doing external scripting of ProcessBook Objects. Now that
means, specifically in this case, writing scripts
that are attached to these buttons right here inside
Excel, that make use of the
ProcessBook Object Model and actually manipulates ProcessBook.
Now, one thing you will notice is if I try to,
if I try to go into Regular
Model, go out of Design Mode and start to execute
these, I am not able to do that.
Let me show you an example. Yeah, I am going to get this message
right here that it's a security breach to try
to run the macros here because they are unsigned. Now, my
security level for macro execution is set to --
currently to high. And, normally, that's a good place for it to be.
When you are doing development work, however,
and you do want to run scripts from within Excel,
you are going to have to come up with some
agreeable safe way of setting up security. So, for
example, in my case, I will go into Security.
I am going to set this to Medium.
This is going to give me the option -- I will be prompted, do I
want to run these macros or not? So, if I try
to -- let's see if I can close and reopen this.
I should be given the prompt of
whether I would like to run these macros or not. Yeah,
this is the prompt I was talking about. In this case, I will go ahead
and enable the macros so that I can go in
and out of Design Mode and execute these macros
if I care to.
When you use external scripting from
Excel or some other application, you
need some mechanism to make relative
references to your current open display. Now I will show you an
example of how you can do this with the Application Object.
I have a sub-routine that's available
in this particular utility.
It's called MYUTILS.pdi. It's a,
it's a little macro that I have written
in, in VBI inside -- ex... or inside
ProcessBook, and it's simply called
ListObjects. And when I run ListObjects, what it's doing
is it's going to list all the Objects on my
current display and then give me a message
box telling me how many Objects there were. As you can
see, it's telling me my current display has eight Symbols.
If I switch over to a different display,
and run that same Utility -- and I can run this
Utility from here. I will have to switch
over to look at all open displays. If I choose
List Objects here and run it, as you can
see, I have a much larger number of Symbols.
I am going through the
display that is current, not just the display
in which the code was written. Now, the way I was able to do that
is in this display right
here, if we look at our code,
what we are using is Application.ActiveDisplay
instead of
Thisdisplay. You notice Thisdisplay has
the same properties and methods.
Thisdisplay represents the current workspace, but it
only represents the current, the current
workspace in which this code resides. By
choosing Application.ActiveDisplay --
[typing]
by choosing Activation -- Application.
ActiveDisplay -- oop, I
misspelled that. There we go. And
IntelliSense should pick that up. There we go. By choosing ActiveDisplay,
the Application Object, it does not
matter which display is active and which
display contains the code. We will always use
whatever is the current active display when we execute the
code. This
is an example of an Excel Spreadsheet. It's
got scripts in it that will manipulate ProcessBook
externally. I will show you an example. I am going to go ahead
and select a tag name from the spreadsheet.
I will choose Open an Existing Procbook Entry. What it's
doing is it's going out and using Visual Basic
scripting to manipulate ProcessBook. In this case, it's
opening a specific book, Unit1,
and it's opening a specific display.
I like using this example because we will get some,
we will get some experience going through the Object Hierarchy
in ProcessBook by using this.
This is all done
by means of some commands that are
fairly standard in the ActiveX
automation world -- commands like Get Object and Create
Object. What we are doing here is we are setting
up some variables. I have a variable here called
appX. appX
is going to be a -- basically
an Application Object, a ProcessBook Application Object.
And we are going to set appX
to have a reference to
whatever is returned by this Get Object Command.
Now the Get Object Command is
used to go out and get the running instance of
ProcessBook and return a
reference to that. Now, if that fails,
that means that ProcessBook's not running. So we then
do a Create Object instead. That's what this
If-Then Syntax is all about. So, this is a, a handy
way to check to see if ProcessBook's running. If
ProcessBook's not running, the Create Object will go ahead
and launch ProcessBook. Now, in
either event, appX is now -- has a
reference to the ProcessBook Application Object
and this give us our
way in to the Object Model inside ProcessBook.
Now, if you are wondering what this
phrase mean, processbook.application.2,
this is a reserved phrase that we have
registered when we installed ProcessBook
so that Windows recognizes that
the Object that it's trying to get is
of a Class called piprocessbook, and the Object
itself is the Application Object. Now, this
.2 indicates which version. If you
omit the .2, we will just go with the most recent version.
So, using Get Object,
we can get access to the ProcessBook
Application. Basically because we have identified
it properly during the registration of ProcessBook,
this is what Windows recognizes as the
ProcessBook Application. We can then use the Get Object
and Create Object to get access to it.
Once we get access to the Processbook
Application Object, we can start drilling down through
it. I would like to demonstrate. Let me close this display.
I will open up a demo that ships with all PI
Systems, and we will look at a display
called Main Column Bottom. And I am going to look in
the Visual Basic Editor, specifically
at the immediate window. Let's look a little bit at
the, the Object that we see
inside this Application Object, all the different Objects.
First let's look at the Application Object itself.
It has a name and it is ProcBook.
Now, the ProcBook Application
has a Collection called the Procbooks Collection.
[typing]
There are currently one ProcessBooks
open at this point. Now, I can drill down through
this. I should say, I can demonstrate
that if we go out and open up other displays,
for example --
let's bring up this second ProcessBook display.
If we go back into the --
let's go back into the -- oh, that's the wrong Visual Basic Editor. There we go.
If we go back into the Visual Basic Editor and look at
the immediate window, you can see now that there are two
Items in the Procbooks Collection. So,
we have an Application Object
with a Procbooks Collection underneath of it.
Now that we know we have got
some Procbooks up, let's take a look at the Procbooks and some of their
Properties. Let's look at Item #1. It has a
Title. The Title of ProcessBook
#1 is PIDemo23. That was the first one I opened
up. The
Title of Procbook #2 is
ActiveX Test. That's the second one I opened up. So, as you
can see, we have individual ProcessBooks. Those
individual, those individual ProcessBooks can be
further explored
by looking at their Entries Collection.
The Entries Collection is the count of --
excuse me, it's the Collection of ProcessBook Entries.
Those are the Items on the Menus in
ProcessBook. So, for example, in my
second ProcessBook, I have got a total of four
entries. We can see that
if we go to our second ProcessBook here.
This was called Unit1. There are the four
entries right there. Now, compare that
to this ProcessBook. It has
much more than four entries. We can see that by
just changing this.
As you can see, there are a total of 33 entries there.
So, each ProcessBook has an Entries
Collection. That's how we get access to the
various entries that you find in ProcessBook.
Let's go just a couple of steps further. We
see that we have 33 entries.
Now, the entries are actually those things that
can be executed to either become displays
or linked displays or
linked ProcessBooks or Operating System Commands.
That's what the Entries Collection is for, is to give you
access to execute the different entries. Now once you
execute a display, it becomes part of the
Displays Collection. So, you can see
that that ProcessBook,
#1 ProcessBook, the first one I opened up, actually has
a Collection called Displays. Now Displays is
called the Open Displays. So, 33
entries are in the ProcessBook, but only one Display is open.
And if I were to look at that particular Display --
let me find
that specific Display -- that's where I
actually have the Display that's currently open.
If I get to that Display that's currently open, I should
be able to find -- let's see, does it have a Title?
No. Let's,
let's look at its, it's
Symbols Collection.
As you can see, there's a Symbols Collection and
it has a count. See, this particular
Item in the Display Collection, it is that
same item that we saw earlier. It is the Main
Column Bottom. It has 114
entries in the Symbols Collection and,
as you can see, we went all the way from the top
Object, the Application Object through the specific
ProcessBook, into the Displays
Collection, to the Symbols Collection. And we could even get
down to looking at individual Symbols from this
point.