I have dedicated lots of time to approach problems like the one you are describing. This short screencast of the of my main programming project, BEST Viewpoints, may help demonstrate the level of complexity of the GUIs I've created. To get to this point I have gone through several redesign and recode cycles and I have learned several lessons which I will summarize in my recommendations below:
- Try to generate functions like myGrid1[list_, options___] which you then use repeatedly to arrange and format output. At the end you will only have a few lines in your code that contain the function Grid. This will help you standardize the appearance of your work and also will help make your program easier to modify and test.
- If possible define or set your input as a list of rules which can then be used along with Replace or ReplaceAll to generate different output nuggets depending on your particular display needs at any given point.
- Whenever possible think of defining functions (myFunction[parameters___]) instead of variables (myVariable1, myVariable2...) in your program. This is somehow difficult to explain, but often programmers use several (or many) variables to point at information that could be referenced or targeted using a single function. Using functions will also help making your application easier to standardize in appearance and way much easier to debug or maintain.
- Beyond the ItemSize option Consider using Pane to control the size of your output. This will allow you to use the Scrollbars option which is often necessary.
- Consider using Grid instead of Row when you know the size of the output. The use of Row may sometimes wrap output in more than one line when you would rather fix the output to one line.
- Using Item[gridElement, myFormatOptions___] in Grid may help getting the format you want in your output. For example, items in the outermost Grid may be aligned to the left (Alignment->Left) but you may want to align element_K to center. You can get this done by using Item[element_K, Alignment->Center].
- Use the "Queued" option when needed. In practical terms this option to Button and related functions may be used to provide enough evaluation time of the action associated to the button.
- The longer your code is the stronger I would suggest that you consider using the Workbench as your main editor. I usually start coding in Mathematica to sketch ideas but once the code starts to shape I move the whole thing to the Wolfram Workbench.
- If you are planning to use Manipulate make sure you are only thinking of small projects or demonstrations. The more ambitious and larger the application you have in mind the higher the chances that Manipulate will not take you where you want. I have already seen several cases where programmers get stuck pushing Manipulate to its limits.
- Starting to use DynamicModule instead of Module is a big jump. They look the same but are very different animals . Don't underestimate the difficulty associated to start creating dynamic GUIS. Carefully read the documentation available, practice, and be patient.
 
As a consultant I'll be glad to help further with training or consulting. Feel free to contact me at ariel.sepulveda@prontoanalytics.com.

Thanks, Sam.  I've seen examples of Computation Drive Report generation in webcasts for the Financial Platform, but without much (or any) "how-to."   Also, I need to use regular Mathematica. The first link you provided shows images of the kinds of reports I want to create, but without the how-to part, either with the Financial Platform or with regular Mathematica.

If you have a Bloomberg license and terminal, you can get Bloomberg data without the Financial Platform (although the FP does seem to make it easy), so I'm not worried about getting the data.  I am worried about positioning the elements that make up the report on the page.  

One possible approach I have thought about is to use Grid[ { {expr1, expr2, expr3}, {expr4, expr5,...}, {...},{},{},... ], to create a report, and CreateDocument[Grid[....]] to put the evaluated expressions into a results notebook.  I could spend a few days trying out this approach, only to find out it's not a good way to do it.  I would appreciate suggestions or links to examples regarding the approach to take.

I'm sure many of the community members have done this kind of thing.

> I admit that getting started with the Workbench was not easy but at this point I do ~95% of my work in it.  Is just the editor that I consider way much more efficient to handle large applications.  Some reasons that quickly come to my mind: 1- get to the last edit point with Control+Q, 2- show and access all instances of a given variable or function name by just selecting it, 3- Multiple Un Do works in the Workbench, and 4 - I have never lost a line of code using the Workbench because it seldom crashes.

> Alternative to Manipulate is most probably DynamicModule which for sure will take you much longer to learn than the time you dedicated to learn using Manipulate.  If your application is simple Manipulate will make it, if not, and you try to force Manipulate to "go beyond its capabilities" you may eventually decide to reconsider implementing your solution using DynamicModule.  In summary, creating demo-type GUIs with Manipulate is just a piece of cake, creating efficient custom made GUIs is a challenge for which perseverance is a fundamental ingredient for success.  I know of several long time Mathematica users who are great function programmers but that have postponed becoming good GUI programmers for reasons they may want to share in this conversation.

>One additional comment.  In my opinion Dynamic deserves comments like those I made for Manipulate: powerful, easy to use, etc.  But be careful because for it to be so easy to use it has default behaviors that often are not what you need to get your GUI where you want.  This is a very interesting topic that deserves its own thread.