From tonight's build, 2.7 b289, a set of command-line arguments have been added, allowing Omniscope to integrate more easily with 3rd party desktop applications.
6 new options have been added:
dmParamName - the name of a parameter to customise
dmParamValue - the value for that parameter
dmParam2Name - another parameter
dmParam2Value
dmParam3Name - another parameter
dmParam3Value
When opening a file via the command line, by supplying the path to the IOK file, the above options are used to customise DataManager parameters. If the file is configured to "Refresh from source: On open", the data in the file will open up reflecting those parameters. You can use this in combination with database blocks, for example, to customise server-side queries according to user choices in the originating 3rd-party desktop application.
For example, the attached file has two DataManager parameters, "Ticker" and "Limit". Both are used in Record Filter blocks to filter the data in different ways.
Download the attached file to your desktop, and execute the following command in a command window:
This launches Omniscope and opens the file, with the first 5 Abbey records from the Bond Prices demo dataset loaded into the Omniscope interface.
The path to installation is typically one of: - C:\Users\YOUR_NAME\AppData\Local\Visokio Omniscope app - C:\Program Files\Visokio Omniscope - C:\Program Files (x86)\Visokio Omniscope
Hi Steve - This is an amazing development. Opens up a lot of opportunities. Thanks for rolling this out.
If only we had an option to run Omniscope in a headless way from command line, that would be dream come true. Is something on those line in the roadmap?
I understand headless to mean "no user interface". What do you mean by this? This feature is about allowing a 3rd party app to launch Omniscope and dynamically customise some aspects of DataManager in the opened file, such as importing data from a database that the user had selected in the 3rd-party application.
Steve - I also mean "no user interface". I am thinking of a situation where we can embed Omniscope commands in scripts. That would allow Desktop users to have some automation.
Sorry Indranil, this feature is specifically NOT for headless use. It is purely used to integrate a 3rd party desktop app with desktop use of Omniscope.
Server edition is required to automate Omniscope in the way you suggest.
Hi Steve - This is looking really great. One thing I (think) I noticed. When creating a param (whuch I use to refer to a database) it works fine with something like -dmParamName=GuruModel -dmParamValueD:\Data\Test.sgm
However with the following it was not happy and started initialising but stalled -dmParamName=GuruModel -dmParamValue=C:\Users\Peter Gordon\Desktop\Test.sgm
I am wondering therefore if this is because in the second case there is a space in the parameter value, which is of course something that may crop up when referring to file locations?
Steve -many thanks - for this. I think this should get us done linking to our models that are created using Access. Great work.
To be cheeky - if something could also be done for SQL Server, which we also use for model databases it would fill all our needs. In our context the host, instance and database name would need to be params. Table name is already there I see. I think we would always use the same driver and port and always use windows authentication with no need for parameters for passwords and user names.
Also of course it would be even nicer if we could parameterise the output to database side too!
Hi - Related to this improvement, we are trying to Open the Omniscope file through Windows Scheduled Tasks using Batch file. It does work nicely in general. But, when the file is password protected, the start up stops at showing the password window. I tried to pass the password using the keywords above; but it is not passed.
Do I need to configure the file differently or use specific keyword for the password passing?
Are you trying to automatically start Omniscope and open a file at a certain time of day?
If so, you should store the file without a password. Removing the password is no worse than storing a plain-text password in the Windows scheduled task configuration, providing you keep the file in a secure location.