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]
PRINT * 
END
-EXIT

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
	return 
}	
WinActivate

^d::  ;CTRL d
;See a whole table/query/hold file
Send TABLE FILE {CTRL DOWN}v{CTRL UP}{ENTER}PRINT * {ENTER}END{ENTER}-EXIT
Send {ENTER}
return

^g::  ;CTRL g
Send -TYPE {CTRL DOWN}v{CTRL UP} is >>&{CTRL DOWN}v{CTRL UP}<<{ENTER}

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

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

Shingles

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

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:
Fiddler
IEZoneAnalyzer
UltraEdit
BeyondCompare
DBVisualizer
TWIGI Find Tool for WebFOCUS

Happy debugging!
Toby Mills, CISSP