Upon creation of a automation script in IBM Control Desk / Maximo an array of implicit variables are created, according to the IBM docs:
Implicit variables are variables that you do not define. These
variables are automatically provided by the framework. Some implicit
variables are valid only when associated with a declared variable
while others are not associated with any other variables.
In addition to implicit variables, a Maximo® business object (MBO) is
also available to every script. You refer to the current business
object by using the mbo reserved word.
From these docs:
https://www.ibm.com/support/knowledgecenter/SSANHD_7.6.0/com.ibm.mbs.doc/autoscript/r_variables_automation_scripts.html
When trying to use mbo with the following code inside a newly created Automation Script with no launch point:
mboSet = mbo.getThisMboSet()
I get the following error message:
NameError: name 'mbo' is not defined
This seems strange to me as mbo is a implicit variable that should be accessible.
I am new to Maximo and don't have enough experience to debug this problem at this point. How would I acces the mbo variable and use it? Thanks in advance.
mbo represents a single psdi.mbo.Mbo from a single psdi.mbo.MboSet (see the JavaDocs), or synonymously a single row from a single table. The Launch Point is what chooses the record to send to your script as mbo.
If you run your automation script directly, via the Test button or by restoring the Execute button, which table and which row from that table should Maximo randomly choose to pass to your script as mbo? The answer to that rhetorical question is "none" -- Maximo should not randomly choose some record from some table but should not define mbo in such cases. Hence, the error is expected behaviour in the situation you presented.
If you want your script to be able to run directly as well as from a launch point, you can check if "mbo" not in locals(): and then set up mbo for yourself. I have dubbed such automation scripts as "On Demand Autoscripts", and I use them regularly. If you spend some quality time with the JavaDocs, you might get there, too!
You say it's a newly created Automation Script with no launch point? How did the script actually run then to get that error? Did you press the test button? If so, that's the problem. The test doesn't run the script in context (where those variables can exist). You will need to create a launch point to trigger your script, then you should see the implicit variables come into play.
Related
I'm a total newbie to Scheme (about 1 week).
I'm registering a script for which the second parameter is an output directory name - via SF-DIRNAME. How do I supply a meaningful default to the front-end widget that does not use host platform-specific names? Ideally, I'd like it to be '/Users/[username]' - or if possible - the Scheme equivalent of ${PWD}. As an illustration, when you create a new image and hit 'Save' for the first time, the default directory there is '/Users/[username]/Documents' - so it must be possible. How does the widget know what your user home directory is? How can this be referred to in the default field of the registration statement? Finally, it would be really nice if Gimp could 'remember' which output directory was selected last time (within the scope of the lifetime of the Gimp instance) and offer that up as the default on the second and subsequent invocations of the script. I've scoured hundreds of other people's scripts, the Gimp community pages and the Scheme documentation and I've found, literally, nothing on this requirement. Thanks in advance. VV
Gimp uses the GTKFileChooser widget, and there is nothing you can do in your script to make it different from the other instances of GTKFileChooser used in Gimp.
But what you supply as a default name can be a variable, it doesn't need to be a static string, and it can be set by any means available in to your Scheme interpreter at the time of registration (looking for the HOME environment variable, for instance).
Btw, if you are new to this, write your scripts in Python, it is both easier and more powerful.
I have some code which has worked in multiple installations for about a year. Today im doing a small change to a control and then another control seems to have developed an issue. When at runtime im getting a 91 error object variable or with block variable not set.
I therefore looked at the problem line which is: -
If Screen.ActiveForm.name = "frmFoutmelding" Then Exit Sub
so I noticed the name was lowercase. if i delete .name and rehit the "dot" then it shows me i can use .Name but as soon as i move from this line it drops back to .name
I've checked for instances of name and it appears everywhere in the code in different modules but i cant find if i have accidentally defined this lowercase name anywhere?
Googling doesn't seem to show much but i feel Im googling the wrong terms
chaps - thanks for your suggestions - this was the first instance of the lowercase name and searching as Jim suggested didn't reveal anything I'm afraid. What I did discover was that this was suddenly being run before any forms had actually been displayed and so the count was 0. I therefore, did an on error to check the form count and exit the sub if it =0 then if not to carry on with the line I thought I was having issues with.
It's likely that you did create a new variable or property called (lower case) name, or that some included reference did the same. It's possible to use reserved words as variable names in some cases, but it requires taking specific steps.
I would first search your code for instances of name As to see if you created a variable (this assumes you use Option Explicit, which is a must IMO). Then search for Property*name with * as a wildcard.
If those fail you could try unchecking references or components to see if any of them define name. If none of that finds anything, please post back here.
Jim Mack covers a lot of the potential issues. I think another is if you typed a lower case '.name' in association with Activeform at some point earlier in the same code module - the VB6 IDE checks in the current module and uses that to define what case to use. Look further up the same code module (sub or function).
Ultimately, check what changes you made by comparing the old source to the new in a file comparison tool like windiff - you do have backups, right?
I've seen a lot of questions about this on the interwebs but no answers. Is there a way to refer to an Automator 'variable' within AppleScript? I'd like to do some string manipulation as part of a workflow. I've worked around this by using Get Variable and passing them into temporary files, but it's kind of ugly.
I was trying the same ting as Steven. My conclusion is that when you run a flow inside the "Automator" application then your applescript can access Automator-varaibles via the Apple Script "Automator Suite" interface. For example:
set my_variable to value of variable "The Variable" of workflow 0 of current application
display dialog my_variable as text
set my_variable to "Test"
But if you save the flow as a stand alone application then it does NOT include the "Automator Suite" into the application and therefore the above script will no longer function :-(
An AppleScript used in a workflow accepts two parameters: input, or the output of the previous workflow, and parameters, the options set in the workflow's UI (if applicable). If the string you are manipulating is part of the workflow's input, it will be in input.
More information is available here.
I have a variable in the MATLAB workspace and I want to pass the variable name and its contents to a function in my GUI.
How do I achieve this task?
I'm not totally sure what you mean when you say "pass the variable name and its contents", but here's one possible solution. After you pass a set of data to a function like so:
some_function(data); %# Pass the variable "data" to a function
You can get the variable name of the input argument from inside the function using INPUTNAME:
function some_function(inputArgument)
name = inputname(1); %# Will return "data" as the name of the input variable
end
EDIT: As pointed out in a comment by High Performance Mark, the variable inputArgument inside the function will contain the values stored in the variable data in the workspace of the caller.
If this question is related to your other most recent question, then why not build the operation into your GUI? You can use guide to create a pushbutton, and place the code under the callback function.
I am assuming that you have created the figure with GUI using the GUIDE, and that you know the 'Tag' names of the GUI objects.
((1)) Open the figure using the GUIDE, ((2)) Open the Property Inspector for the figure (select the background, the light-gray gridded area of the figure, and double-click over it, to make the Property Inspector for the figure to pop-up), ((3)) Turn the 'HandleVisibility' 'on' (by default, it may be set as 'callback'), ((4)) Save the figure and close the GUIDE, and finally ((5)) set the GUI property values from the MATLAB Console (or "Command Window") using some parameters that are currently available on your workspace.
I hope this helps.
Best,
Y.T.
Greetings,
My company uses Peoplesoft for its financials and HR. Our implementation is on Oracle databases. Setting global_names = TRUE forces you to name your database link the same as the target. My question is does anyone know the ramification of setting global_names to false in the init.ora parameter file?
More specifically, I want one of our environments (global_names = true) to have a database link called PRODLINK and it will point to a production HR database. Another environment (where global_names = false) will also have a link called PRODLINK but it will point to a non-production database. To further complicate it, one database environment is at Oracle 9.2 while the other is at Oracle 10.2
I have searched for an answer for this but can't find one. Thanks in advance for your any help/advice you can offer up.
J.C.
The upside of having global_names=TRUE is simply that it forces you to use names for database links that indicate clearly what database they connect to. Setting it to FALSE simply removes this restriction; the downside is that it will allow you to make links with names that could be confusing. In the perverse case, if you had databases A, B, and C, you could create a link in A called "B" but pointing to C.
You could also consider it a security issue, in that setting global_names=FALSE makes it slightly possible that someone could maliciously change the definition of a link, causing either inappropriate access or data damage. I can't think of a specific scenario for this though.
Overall, there isn't a big downside to setting it FALSE. However, there are a couple of other options you could consider.
One is to keep the global setting TRUE but reset it to FALSE at a session level in the code that needs it. We do this at my site because there is only one application that requires the use of "incorrectly" named links. This method ensures that anyone using the link interactively or writing code that uses it will be reminded that the name does not match the destination.
Another is to keep global_names=TRUE, so the environments use different link names, but make the link name a parameter or configuration option in your code. For instance, if you have scripts that build PL/SQL packages, you could make the link name a parameter of the script.