Focal Point Banner

As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

New TIBCO Community Coming Soon
In early summer, TIBCO plans to launch a new community—with a new user experience, enhanced search, and expanded capabilities for member engagement with answers and discussions! In advance of that, the current myibi community will be retired on April 30. We will continue to provide updates here on both the retirement of myibi and the new community launch.

What You Need to Know about Our New Community
We value the wealth of knowledge and engagement shared by community members and hope the new community will continue cultivating networking, knowledge sharing, and discussion.

During the transition period, from April 20th until the new community is launched this summer, myibi users should access the TIBCO WebFOCUS page to engage.

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [CLOSED] Little AutoHotkey helper script

Read-Only Read-Only Topic
[CLOSED] Little AutoHotkey helper script
Platinum Member
I like to use AutoHotkey to help me out with routine clicks/keystrokes. It was great to build a bot in World of WarCraft... I digress.

To make use of this, you need to have something in your clipboard, like the name of a variable or holdfile. And you'll need to put the cursor in a spot that makes sense. This script, if it is running will spit out:

If you press CTRL+D
TABLE FILE [contents of clipboard]

If you press CTRL+G
-TYPE [contents of clipboard]is >>&[contents of clipboard]<<

And this is the autohotkey script...
IfWinNotActive App Studio 
	Msgbox, This shortcut only works with App Studio

^d::  ;CTRL d
;See a whole table/query/hold file
Send {ENTER}

^g::  ;CTRL g

What do you guys use to help debug/code fex files?

This message has been edited. Last edited by: FP Mod Chuck,

WebFOCUS 8201, SP 0.1, Windows 7, HTML
Posts: 190 | Registered: May 19, 2017Report This Post
posted Hide Post

The most common debugging is to put -SET &ECHO=ALL; at thh begining of the fex. It will echo allthe code executed. You need to use html output and probably view the source of the output

Thank you for using Focal Point!

Chuck Wolff - Focal Point Moderator
WebFOCUS 7x and 8x, Windows, Linux All output Formats
Posts: 2128 | Location: Customer Support | Registered: April 12, 2005Report This Post
Gold member
posted Hide Post
Hey Shingles,

This is a great thread to start up. I worked Tech Support for 5 years and have a tad over 35 years of messing with IBI products. I find that most of the debugging of cases I ended up with had to do with understanding the flow of information from the time it:

1) leaves your browser (lets say you're executing a report and you've filled in a parameter page).
2) Hits the Web Application Server which is running the WebFOCUS Client (more often lately, I keep hearing this referred to as 'the middle tier').
3) then the request leaves the WF Client and hits the WebFOCUS Reporting Server (aka WFRS for short).
4) the the WFRS hits the database (RDBMS) to collect data.
5) back to the WFRS to sort/sum and build the output.
6) back to the middle tier
7) back to your Web Browser that started the whole thing.
8) Now your browser must be capable of rendering the output that it's sent.

When someone reports a problem, you need to isolate it as best you can. For example, if you report is just dying, try NOT running it from the WF Client -instead try to run it just from the WFRS console. If you can get it to fail on the WFRS, that'll tell us a lot. If it works on the WFRS but not from the Client, that tells us things too.

So let me tell you my approach to troubleshooting at the various levels. Essentially we can narrow down my list above to a few things:

1) your browser
2) The WF Client running on it's Web Application Server (like Tomcat or websphere etc).
3) the WFRS
4) the RDBMS

So lets say you use IE as your browser. The tools I use to dig in for information are:

IE -> WF Client - Use Fiddler HTTP traffic watcher
WFClient -> WFRS - use whatever traces you like on the WF Client Admin Console Diagnostics.
WFRS -> RDBMS (or just WFRS in general) - Make up a 'savediag'. How to do a Savediag

RDBMS tracing - talk to your DBA for help here unless you think it's not reaching the RDBMS at all. Then check all your parms. To test to see if your WFRS can even hit that database from you host PC (assuming windows here), we used the free version of DB Visualizer

With these basic tools you can watch traffic coming and going from your PC (including traffic that AppStudio generates -it uses HTTP to communicate, so you can use Fiddler to watch that traffic).

The only one I've left out is where a report generates okay for one person's IE browser, but does not work for another person. Switch the people and have them try each others machine. that may give a clue that it's a PC setting. Have you ever looked at all the settings that are possible in IE under the various security 'zones'? Holy cow, it's a lot of radio butons to look at. Pages of them.

To compare one IE setup to another, I really liked using IE Zone Analyzer. It tells you LOTS of good info. Like to both PC's think the WF client is in the IntrAnet zone -or does one of them think the WF Client is on the IntERnet zone. That'll make the rules behave differently.

Maybe one day when I have lots of time, I can start a thread on each of these tools.

Hopefully most of you won't need to dig in so far, but I'd highly recommend getting Fiddler if your company will allow it. It really helps to see your requests coming and going. You might, for example, see that Fiddler shows a whole Excel file was delivered to your PC, but your PC acts like it never saw it or it can't open it. Isn't it at least nice to know that the Excel file arrived? So it's not the WFRS and it's not the RDBMS and it's probably not even the Client (it might be mime types though). Start looking at your PC at that point.

So &ECHO=ALL is certainly a start, but what will really help you debug is to bust out all your tools that let you see each step of the way during the life cycle of running something.

I also use Macro's in UltraEdit to globally change all the > to > etc in HTML source that pops up with you view source. I prefer to make it readable by me without having to interpret all that.

And I make regular use of Beyond Compare to compare files between version or machines to check configuration files or source code.

Lastly, when I can't find a piece of code, if I just know a fieldname or some string in the focexec I'm looking for but can't recall where I put it, I use the TWIGI Find Tool for WF. It helps me to real impact analysis by being able to generate an Excel spreadsheet for me of everything it finds in the repository that might be impacted.

Let me know if you guys have questions about any of these. Mostly focus on narrowing down the issue so you know where to start tracing.

Recap of 3rd party products I use regularly:
TWIGI Find Tool for WebFOCUS

Happy debugging!
Toby Mills, CISSP
Posts: 62 | Registered: October 31, 2006Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [CLOSED] Little AutoHotkey helper script

Copyright © 1996-2020 Information Builders