What’s the quickest way of opening BusObj and displaying a report without giving the user any options other than the basics (eg File - Preview, Print, Close etc)
Through OLE script I can turn off all toolbars by looping through them but I can’t see the best way of turning off all (well, the majority of) menu bar commands. Basically I want the user module to become a report ‘reader’ only.
If anyone has any code (I can’t find what I want on the CD) then I would be most grateful.
What’s the quickest way of opening BusObj and displaying a report without giving the user any options other than the basics (eg File - Preview, Print, Close etc)
Through OLE script I can turn off all toolbars by looping through them but I can’t see the best way of turning off all (well, the majority of) menu bar commands. Basically I want the user module to become a report ‘reader’ only.
Hi Jonathan:
If you want to disable the commands at the user level, try disabling them in the repository for a particular user/group.
Regards,
Chander Aggarwal
The home of BusinessObjects Essentials – Worlds’s first full multimedia computer based training for BusinessObjects!
What’s the quickest way of opening BusObj and displaying a report without
giving the user any options other than the basics (eg File - Preview, Print, Close etc)
What about using the Filters or Scanner application as an idea. You could open up the
document as an OLE Object and have you’re own Open, Print etc buttons that interact
with BusObj.
Hayden Gill
Senior Analyst Programmer
The University of Queensland
Brisbane, Australia
You can use the BOCommands class to disable most menu features, including toolbars, of the product.
Robert
Schmidt Interactive Software, Inc.
What’s the quickest way of opening BusObj and displaying a report without giving the user any options other than the basics (eg File - Preview,
Print,
Close etc)
Through OLE script I can turn off all toolbars by looping through them but
I
can’t see the best way of turning off all (well, the majority of) menu bar commands. Basically I want the user module to become a report ‘reader’ only.
If you want to disable the commands at the user level, try
disabling them
in the repository for a particular user/group.
This would be the easy solution if the same users weren’t also using the ad-hoc functionality of BusObj. What we are trying to do is to have BusObj on most desktops but change the way people interact with it based on the needs/demands of the report delivering mechanism.
We have a client-server app (let’s say called ApplicationA) which has predefined reports. We also have BusObj as an ad-hoc reporting tool. What we need to implement is a means by which ApplicationA can display it’s reports using BusObj with barely any functionality for the majority of users. The same users can however, at other times, create their own reports from available universes. What I don’t want is to use full blown OLE to use the BusObj object model and display reports inside PowerBuilder/VB apps etc. I want a standard way of calling BusObj in effectively a read-only (ie non-multifunctional) state.
At the end of the day, I want one reporting tool which can be used in a variety of ways but with minimal coding. I also don’t want users to conciously have to switch between ApplicationA and BusObj to display a predefined report.
What about using the Filters or Scanner application as an idea.
You could
open up the
document as an OLE Object and have you’re own Open, Print etc
buttons that
interact
with BusObj.
thanks for your reply. Unfortunately, the Filters and Scanner examples are exactly what I don’t want i.e using full blown OLE to use the BusObj object model and display reports inside PowerBuilder/VB apps etc. I want a standard way of calling BusObj in effectively a read-only (ie non-multifunctional) state. Ideally, the solution would be to start BusObj with command line parameters (even calling a script) to turn off the functionality that I don’t want users to have.
Here is a work around. It’s not the best, but it does get you out of developing OLE applications.
Have two sets of logons for users that need both “full blown” BusObj and “trimmed down” BusObj. Put no command restrictions on one group and limit the other group.
Best Regards,
Andrew J. Erthal Post Sales
Consultant - Central
Business Objects Americas
NY Office (212) 626-2626 St. Louis Office (314)
209-1994 aerthal@businessobjects.com St. Louis Fax (314) 209-7926
From: Cirkel, Jonathan D [SMTP:jc14547@GLAXOWELLCOME.CO.UK] Sent: Wednesday, June 17, 1998 4:56 AM
Chander,
you said,
If you want to disable the commands at the user level,
try
disabling them
in the repository for a particular user/group.
This would be the easy solution if the same users weren’t also using the ad-hoc functionality of BusObj. What we are trying to do is to have BusObj
on most desktops but change the way people interact with it based on the needs/demands of the report delivering mechanism.
We have a client-server app (let’s say called ApplicationA) which has predefined reports. We also have BusObj as an ad-hoc reporting tool. What
we need to implement is a means by which ApplicationA can display it’s reports using BusObj with barely any functionality for the majority of users. The same users can however, at other times, create their own reports
from available universes. What I don’t want is to use full blown OLE to use
the BusObj object model and display reports inside PowerBuilder/VB apps etc.
I want a standard way of calling BusObj in effectively a read-only (ie non-multifunctional) state.
At the end of the day, I want one reporting tool which can be used in a variety of ways but with minimal coding. I also don’t want users to conciously have to switch between ApplicationA and BusObj to display a predefined report.
In a message dated 98-06-17 16:47:06 EDT, you write:
Ideally, the solution would be to start BusObj with command line parameters (even calling a script) to turn off the functionality that I don’t want users to have.
Combining some earlier answers: can you create a BusObj “report only” user in your security domain? And then use that user to “log in” to BusObj via ApplicationA?
In other words, set up a very restricted user in the standard Business Objects repository. Turn off all of the features of the program that you don’t want the report user to see. Then use that user to log in to BusObj to display your report.
Also, there is a BusinessObjects program called “Reporter” that comes preconfigured as a read only version of BusinessObjects. I don’t know if it supports all of the OLE features that the full client does, but perhaps it is an option? It is an extra cost program… not part of the standard Business Objects license.
Regards,
Dave Rathbun
Integra Solutions www.islink.com See you in Orlando in '98!
Indeed opening the document as an OLE object gives you’re own Open and Print buttons, but what about Previeuw?
Hayden Gill H.Gill@MAILBOX.UQ.EDU.AU 17/06/98 1:07:45 >>>
What’s the quickest way of opening BusObj and displaying a report without
giving the user any options other than the basics (eg File - Preview, Print, Close etc)
What about using the Filters or Scanner application as an idea. You could open up the
document as an OLE Object and have you’re own Open, Print etc buttons that interact
with BusObj.
from available universes. What I don’t want is to use full blown OLE to use the BusObj object model and display reports inside
PowerBuilder/VB apps etc.
I want a standard way of calling BusObj in effectively a read-only (ie non-multifunctional) state.
It really does sound like OLE would solve your problem - I wouldn’t have thought
that you’d need TOO much code to allow a user to select a report and display it
in a container, just add a few buttons for print etc. which are all more or less
single calls to BO. Or are there other issues with using the BO Object Model ?
At the end of the day, I want one reporting tool which can be used in a variety of ways but with minimal coding. I also don’t want users to conciously have to switch between ApplicationA and BusObj to display a predefined report.
The alternative is that for those users who NEVER create reports, I once understood
that a read-only version of BO was available ?!? I guess you may even find if you
speak to them that this is the same software with some registry settings changed
(thought they may not tell you that). If that was the case you could manipulate them
yourself to control the state. Just a thought.
You’ll probably want to look at hiding the login box too ? That’s been discussed on here
before, but I think it’s just a matter of defing the connection in terms of variables
which you set the value from your application using the BO Object Model - I’ve got the
info somewhere.