Amper autoprompting treats \ as an escape. Double up \\ to code a backslash.

Plinks ! also cause much problems.

Still like amperautoprompting tho!

I do have the double backslash, and the bug has been confirmed by Information Builders. It only happens in 7.6

Thanks for the plink info!

Issues in the autoprompt discussions:
1. Single threading: Devstudio has an option to control if you want each execute to go into a NEW window or reuse the last window. Options->General->”use new browser to execute”.
2. The old autoprompt screen (ala 53x) is being fixed in 76x. It works in 71x if you turn it on.
3. The backslash problem is being worked on.
4. You can specify which autoprompt screen to use as a parameter.. In 71x, it was a full file path. In 76x we broke that into two varaiables, one for the folder location, and the other for the transformation filename. We envisioned that the file will be selectable from development tools in the future. In 76 you can code fexs to use different styles.
5. Autocomplete is working for me when I turn it on in the browser. Susan has cut over to the old screen. Does anybody have a repro for this behavior (old autocompletes, new does not)? If so, please open a case.
6. There has been a background effort for an additional autoprompt layout with the fields in a top pane and the report in the lower pane (or new window). Watch for future announcements.

We had generally positive response when we introduced the new look at 2005 Summit. There was one camp that said, “yes – but put the variables across the top”. And the comments here show that some prefer the old plain and simple. Clearly “beauty is in the eye of the beholder.” We do not want to be the arbitrators of style, so, when feasible, we will give you choices.

Thank you Brian! Excellent news and help!

About #3

Adriane has given me a workaround for the USE statement being broken and I would like to share it with you guys:

change

FROM
\\ntport\mips\2xxxxxxxx\23xxxxxx\23562517

TO
\\\\ntport\\mips\\2xxxxxxxx\\23xxxxxx\\23562517\\CARI.FOC

Works nicely!

Carol

This is directed to Brian Suter's post of "January 09,007 10:46 AM" but any other responses will be equally appreciated.

I'm searching for a workaround to the 7.1.3 autoprompt 'Run-Once-Only' problem that's become our development and migration 'show stopper'. (see my post of 29Dec06, and Case #22302060).

re: #2 - I'd like to try reverting to the old 5.3.x autoprompt. How do I turn it on? #4 hints that I need to supply two &AMBERVARs but does not identify them nor explain their context.

re: #4 - How do I code a 7.6.x fex to specify the 'style' to use. Are you saying that a fex can direct to autoprompt in the 'style' of 5.3.x or 7.1.x?

I question the basic concept of 7.1.x's autoprompt presentation style, whether 'down the left' or 'across the top'. Both would, at fex-end, display the input controls simultaneously with the report they produced; both would show in the same window.

Was the intent of this to document at report 'read time' both the parameters and the resulting report? Reports controlled by external parameters, which is what autoprompt facilitates, have always been suceptible to the 'look-alike' problem in which editions run with different control values and/or at different times tend to look confusingly the same. If an edition of such a report is saved or printed and viewed at a later time, one must consider if the reader can confirm or reconstruct the specifications of the report's production. If the user can't, conceptual errors and data misunderstandings become a hazard. External parameters often control the range of data presented. Sometimes the range is obvious in the the report's content, sometimes it is not.

The 'new' autoprompt style forces the input control specifications to be displayed along with their associated output. This may be a worthwhile feature for casual and novice developers, but the time-tested and foolproof solution is for a report's headings to 'echo' the value of every input parameter whose setting is not inherently obvious from a viewing of the output. The 'echo' method also allows a single fex to produce unambiguous output when executed in either the adhoc/MRE/Dashboard or batch/RCaster methods. It's nice to be able to run the same report adhoc when an RCaster receipiant says "I didn't get my report. Can you run it again?"

The case you mention is rather long. The last comment implies that a small change will fix the problem. I run autoprompt repeatedly in MRE with no problem, so there is something specific with your request that is surfacing the problem. Best to wrap that up with CSS.

In 71x you have two ways to set the autoprompt.
The first is global on the “parameter prompting” tab of the WebFOCUS Admin console.
The second is that it can be overridden on the requesting URL like this:
/ibi_apps/WFServlet?IBIF_ex=AUTO/AMISS&IBIF_external_xsl=c:/ibi/webfocus716/ibi_html/javaassist/ibi/html/describe/autoprompt_old.xsl

As you can see, the override is lengthy, so in 76x we broke the variable into two: IBIF_describe_xsl_location and IBIF_describe_xsl. The first points at the directory, the second has the file name. These can be set in the admin console or on the request URL.

As for setting it in the fex in 76x…. I was a bit ahead of myself since we have not released that yet (QA has not finished). Once it passes QA, we will let you know about it.

As for your comment about relecting criteria in headers. Absolutely. The autoprompt facility is not made to be used to PRINT a report. It is made for developers and quick deployment to users. Since the user can launch the report in a new window, the report should be able to "stand on its own". Moreover, the right pane could be PDF which will only print by itself. So the safe bet is make the report self documenting enough to meet your business needs.