Hi Everyone

I was just wondering. How many of you actually use the Dev Studio Gui interface? My guess is that nobody does. Personally I use Textpad to do my coding, but sometimes I use the GUI to write my joins.

How about the rest of you?

Have a nice weekend everyone

Jodye

"developers dont use gui tools " is the mantra.
I use Domain Builder in MRE and hand code everything. From time to time, i use graph assist from Domain Builder to get some syntax...pretty much the same way i use FrontPage to get some syntax.
I too use TextPad out of habit, but Ultra Edit is quite swell, especially with the focus code add-in.

Susannah, are you talking about wordfiles in UltraEdit, or something else?

Also, is there a way to have UltraEdit launched as the default editor, it seems inconvenient to launch it from the command menu and cut and paste code back into the standard editor.

not sure what you mean by 'word' files in Ultraedit, TCHR. do you mean MSWord? no, i just use ultraedit for text editing, of fexes and launch pages.
It is my default for right-click-view-source..which is nice. That just happened on install, i didn't set it.
As for cut&paste..no need. You can just open the fex directly in Ultra Edit from the directory where the fex lives. You don't need to cut and paste back into anything. You don't need Devstu open at all to work that way..of course you have to carefully control your fex naming conventions so you can find the fex you want to edit. TextPad has a nice 'find in files' feature for global searching, and UltraEdit has a nice 'change in files' feature for global changing. Both show line numbers, thats pretty much the deal breaker for both mre-db and devstu.

I've been coding in Focus for over 15 years. That being said, these days I do 95% or more of my work through the gui tools. I find the tools an huge time saver! There isn't much that you can't do in the gui these days ... if you decide to learn and use it.

When I leave a site, someone has to maintain what I've done. It is a lot easier to maintain an application with a mouse then a keyboard.

We purchased dev studio about a year ago. We had 4 java developers and 3 business analysts who had familiarity with Access and Crystal reports.

We gave the gui to our business analysts the 'real' developers would not touch it.

Two of the three BA's use the GUI full-time and are very productive. There are some things you can't do with the GUI and once you 'edit' the fex using the text editor you can't go back but we use the gui very effectively in our environment - it is a great tool for non-developers

I too, am a long time coder.

Unfortunately, I have always had difficulty spelling words like FILE. The gui makes my life a great deal easier.

As dhagen says, if you take the time to learn and use the tool, it's a great time saver. Fewer typos to deal with, and I've never coded a mulit-verb request faster.

another old Focus programmer here!

I can type my code using TextPad much quicker than learn the GUI.

Our User's are using the GUI, but I find it doesn't write efficient code against large tables. And, there are things the GUI just can't do.

Lastly, once you manually edit your code, you can't go back!

Carol

One day, when the time is right, I will compile and post the 137 things I've found that annoy me about Dev Studio Resource Layout/Report Painter.

Development naturally lends itself to writing code by hand and GUI's were meant to make that task easier for everyone. Our product is no exception to either of those two facts. The beauty of WebFOCUS is that you have both language and GUI so you can take your pick. Our ultimate goal is to make the GUI just as powerful and efficent as our language. That way everyone from end users to developers can write the most complicated reports with ease. The next release of Dev Studio (7.1) will contain many enhancments that bridge the gap between our language and our GUI. Some of these enhancments include: consolidation/improvement of Metadata Management, MATCH FILE and Dialogue Manager support, new PDF Layout Painter, and much more.

Enhancments like these may actually win you coders over! Ok, I won't get carried away.

Pietro, The right time is now. Let us know what bugs you about the Report/Layout Painter - we want to know so we can alleviate any annoyances you may have with the tools. If it annoys you, I'm sure it annoys others and we want to take care of that as quickly as possible.

Thanks,
Brian Carter
Product Management

Brian, developers don't care. we don't want someone ELSE's brain in between us and our work.
dev stu is just NOT important to us. True, we can encrypt a fex in devstu, but then caster can't run it, so there's just no point to having dev stu at all, for a developer. And to hear how much effort you're putting in to it ( for sales only) just means you're NOT putting effort into what we DO need, and the way you refer to us

quote:

you coders

??? just reinforces that.
What we DO NEED is for Excel to be able to have pre-coded ranges. That opens up a whole universe of possibility. Excel output can now feed into our existing templates, etc. AND we need excel formulae to respect parentheses, which they dont now (at least in 525), which is just whacky! AND we need pivot tables to respect formulae..we realize that's non-trivial, but we need it.

Hi Susannah

I couldn't agree more. I started this whole thread because I never use the GUI. But its the same with all GUIs. Look at HTML. You can write it by hand and lookup a few things if you aren't sure of the syntax, or you can use gui like Frontpage, Dreamweaver etc and have 5000 lines of extra garbage in the html.

Actually the real reason that we dont use the gui is that our fexes are full of tons of gotos and dialogue manager code. Also, it is honestly faster to type the fexes by hand than to use the gui.

But they do have to support the gui because there clearly is a market for it.

Also speaking of excel, we really need a way to output multiple reports into multiple worksheets in one excel file. Last time I checked, this was impossible. Is this stil the case?

I personally don't like using the gui tool it's to slow but I now have to re-develop all our reports so that the gui tool can open them so that the any users can maintain them. Lots of fun.

You can output reports to multiple worksheets in 5.3.x.

Here is some code for you.


TABLE FILE CAR
PRINT
SALES
BY COUNTRY NOPRINT
BY CAR
BY MODEL
ON TABLE PCHOLD FORMAT EXL2K BYTOC
ON TABLE SET STYLE *
TYPE=REPORT, STYLE=BOLD, COLOR=YELLOW, BACKCOLOR=BLACK,$
TYPE=DATA, COLUMN=CAR, COLOR=BLUE, BACKCOLOR=YELLOW, $
END

This message has been edited. Last edited by: <Mabel>,

This note is to Brian Carter, Product Management.

Hi Brian

Where would you like us to post our list of "137 things I've found that annoy me about Dev Studio Resource Layout/Report Painter" as Pietro so aptly put it a few posts ago?

Here in this topic?

Perhaps you could create a topic expressly for the purpose of capturing our frustrations with the GUI. None of us wants to spend more time coding than we need to. That's why many of us have been using FOCUS for decades.

As a long-time Macintosh user, I appreciate an elegant GUI. With Mac OS X, I get an elegant GUI with consistent behavior and the unix command line under the covers. This combination of ease-of-use and power is what I was hoping for in WebFOCUS.

CurtisA's comment

"but I now have to re-develop all our reports so that the gui tool can open them so that the any users can maintain them"

expresses much of our frustration.

Thanks. Suzy

Good morning everyone!

First, I'd like to briefly introduce myself. I have recently accepted Monica McDonald's position as Marketing Manager (btw, MM is doing great). Although I am new to the Focal Point community, I have been with Information Builders for almost six years. The one thing I enjoy most about IB is the collaborate environment seeking to enhance and improve the product, business, and customer relations.

With that, we would appreciate the opportunity to learn all of your concerns regarding the topic at hand: Developer Studio. I think Suzy's suggestion is the best...let's open a new discussion. I've asked Brian to begin the dialogue...Brian, take it away!

Thanks everyone!

Maryellen
212-736-4433, x3654

Hello all,

I've been programming in FOCUS for about 3yrs now and I know when I started out, using the GUI was a great tool to learn the basics of the language and figure out how things are organized... I shortly realized that once I got into bigger reports that needed customization to the information (calculations, defines, joins and what not) it took a lot less time coding it then trying to figure out the GUI. It was a great beginner tool... but that's where I pretty much left it.

As for how I make my programs, I use UltraEdit as my editor and the odd time, execute adhoc queries in the the DevStudio Console mode.

And for the 137 list of things that are annoying in DevStudio... I'll be adding to that list

Leo

I agree with most of this. Like any other "tool" the "new GUI's" take all the glory away from real analysts and developers and make it easy for �newbies� (n00bz) to get all the glory. While I can develop, from conceptual functional requirements to complete implementation, large scale systems the n00bz come in and create similar results with much more code (and system cycles) then needed. Thus, many of today�s applications are �written� through the use of GUI �s with many more lines of code then are really necessary. But, they are easier for the n00bz to understand. So, where do we draw the line? �Quick & Easy GUI� or Efficient, both of which may be accurate.

This brings to remembrance a comment made by an IBI consultant, who asked: �Do you want it quick, efficient, or accurate. You can�t have them all.� (paraphrased). That was just the tip of the iceberg� It brings us to today. I, for one (and it sounds like I�m not alone in this), like the �old school� � manual coding methodology. Just compare HTML web pages that are created in notepad to those created in FrontPage, MS Word or many of the others that are out there. FOCUS code is the same way.

Hi everyone,

I am behind ,I know, but I hope this reply will be read anyway...

I agree with most of you: GUI is nice, but coding is many times the way to go. For me the most important reason for is: real life is not just as easy and nice as a GUI can reflect . CurtisA I really don't envy you. I would go nuts having to 'translate' all my fexes !!!! And by the way: it is more than questionable to me.

Real life is 99% not just one input table (or simple joined structure), a DEFINE, a TABLE and here you go with your output. There may be to many input tables, so you have to collect some of them in an extra pass and MATCH to the rest of the data. There may be the need for extra report lines not producable by SUBTOTAL etc., so McGyver has to take over. There are many other exemples like this.

Suzy_smith, you wrote something, that summarizes many statements in this thread. It's the combination (I myself think, that WF is quite close to it). The nice GUI (that should be developped more and more) and the strong machine under the hood.
I use DevStudio to what I call 'playing around'. Try out new features, find out how some code details are used by WF (the GUI) itself, sometimes to get a start for a new program. But the real work is done in code editor (either in DevStudio (is this still TED ?) or with UltraEdit outside DevStudio).

BrianC: Just one little example of a bug in Resource Layout Painter (that's by now is already in Product Division to be corrected): after every Save of my page, it added extra line breaks. As developping is always an iterative process, I have to save it a lot of times - until the module is too big and RLP is not able to open it anymore. I think the 137 of Pietro are about from the same category.
Brian, for the next version of RLP go out into the field, ask your heavy customers what they would like to do with RLP and try, if you can do it.
And finally: as we are developpers we like to know, what's going on behind. But in tools like RLP you have introduced so much HTML, CSS and JS with external modules delivered with the product, that we don't know what's going on (except you take the 2 weeks and try to figure out, what all these JS are doing). Make it transparent, provide us with documentation about these things. So we would know what to do, when we would like to change just one of the components created by RLP to fit a bit more our actual needs.
If we don't know what's going on, it's suspicious. So we don't use it !