forums.silverfrost.com

[Mike Cheek]

Folks,

On a very part time basis I've been converting an old MSDOS fortran program of mine to Silverfrost. 33,000 lines of fortran. It's now successfully compiling and at least launches and starts to run in a Windows 7 console box. No issues really with the fortran part.

Bear in mind I have a full time day job and family, so my off hours programming time is limited. But I am a chemical engineer and this program I wrote many years ago amazingly still has relevance and addresses a little niche problem that no one else seems to address very well. It is my judgment it still has value, and thus I am working on it, catch as catch can.

Once I get the fortran running, I originally thought I would develop a WinForm wraparound. Then they came out with WPF and I thought maybe I should learn XAML although people advise it has a steep learning curve. Now of course they're coming out with VS Studio 2012 and apparently they are de-emphasizing even XAML and WPF. This is all a bit confusing and discouraging to me, as I'm sure it is to many of you.

OK, here's what I'm planning to do. I'm just going to focus on developing a simple Winform wraparound. That's really as much time as I would have anyway. I realistically don't have time to learn entire new paradigms anyway. I have VS 2010 and so I can develop Winforms and integrate the fortran in this way. As it stands, I'm not sure it's worth for someone with such limited time as myself to go running off in these new directions. Besides, it seems Microsoft may be moving away even from WPF themselves, much less Winforms, so why spend all that pain learning XAML?

Any thoughts? Thanks in advance, Mike
_________________
Mike Cheek

[LitusSaxonicum]

Mike,
My thoughts, for what they are worth, on your questions(s). You can, with FTN95, produce a fully-functional Windows application by using .NET or Clearwin+. I use the latter route, and have been in the position you are now in.
Your Fortran program probably reads a data file, processes it, and then produces an output file. This probably now works just the same as it ever did but as a console application, but instead of consuming all the resources, and running for maybe hours, works in a corner of RAM on a cheap PC, and executes in seconds or minutes. To convert this from a DOS console window to the equivalent Windows console window, all it takes is a WINAPP directive: time: less than 5 minutes.
The next step is to have interactive input of file names for input and output. The easiest way to do this is to put up 3 buttons: ‘input file name’, ‘output file name’, and ‘go’, with the ‘go button only enabled after input and output file names have been selected. This may take a day or so. You make your original program a subroutine, and run it if the ‘go’ button is pressed. After you have run that 3 or 4 times, you will appreciate that it isn’t a real Windows Application! The step that follows is to play around with drawing whatever the results of your program mean when the run has successfully completed: time for that probably a month or two.
Your post suggested using ‘forms’ suggests to me that your user interface envisages users typing numbers &/or text into forms, basically creating an input file. I understand that this is comparatively easy in .NET, and it isn’t easy in Clearwin. Nevertheless, I’d imagine as a part time job you might get that running in 6 months. If you are the main user, you will ask yourself at the end of it: “All that effort, why isn’t it any better than creating a datafile in a text editor?” It still won’t look much like a proper windows application.
As this is a part time job for you, look to spend at least 2 years getting something running that has a menu bar, toolbar, interactive input of data (not typing numbers into forms), and graphical presentation of results. You will want a searchable indexed Help file, and a proper Setup routine that properly associates this program’s data files with it. It could easily take 2 more years to get it running how you like it, so that you move from the converted DOS version to using and liking your Windows efforts.
I suggest that you set your program aside for a while, and concentrate on learning how to create a Windows program with a menubar, learn how callback routines are used to service every user interaction, and all the while remember that your current program will eventually be just a single subroutine call. I did mine in Clearwin, and recommend that route. There is enough extra to learn without all the intricacies of .NET!
Eddie

[Mike Cheek]

Eddie,

Thanks for your input. I will give ClearWin a look!

Mike
_________________
Mike Cheek

[JohnCampbell]

I have written a number of front ends to do this. It contains a simple menu system with a set of responses to a menu system, to provide:
FILE > OPEN : open a file
EDIT > Key_variables : a few edit screens to edit a few key parameters, but keep the bulk of the data defined in the data file.
RUN > START or CONTINUE : some control of the run
INTERUPT : that can stop the program at fixed intervals along the run ( not anywhere)
DISPLAY > some options to select how the results are displayed, once the run is complete.
VIEW : some options to control how the graphics is displayed while the program is running.
REPORT > some options to report results either to the screen, text file or simple OUTPUT text screen.
FILE > EXIT: end of the program

Once you have one program it is easy to adapt to other programs.
The edit boxes can be just simple %rd or %rf boxes which list some key parameters. If the data to edit is in an array, that gets a bit more complicated if the array is not small and of fixed size, say array(6).

My display is based on a %gr where both lines and text can be displayed. The graphics can be simple, but redisplayed as the program progresses (say every few minutes of a 1 year simulation run. The updated display of a simple graphics is very effective. It does not require complex graphics. The dynamic change provides a very good understanding of the solution.
If the solution is not iterative, then the single graphical display needs to be more complex, but you would be surprised how effective simple graphics can be, even a single chart !

I have these very simple edit boxes and run the program on the wall with a projector. The impact on the client, by performing simple "what if" displays is very effective.

I'd like to be able to provide a simple template program, as it is much easier to change a simple program that is working. (My program is based on samples from Paul, Robert and Andrew over the years). Unfortunately I also suffer from a serious lack of time.

We should investigate a suitable forum/platform to provide this.

John

[LitusSaxonicum]

Mike and John,

Those simple interfaces grow to be more than simple year on year, and while they are legitimate windows applications, they aren't fully-fledged ones in the sense of things like Excel or Word.

The really time consuming part, especially for someone who isn't devoting his time wholly to the job is to figure out a graphical system for representing and interacting with the dataset, and get it reasonably bug-free! I've done that, while working part time on it, including going up the learning curve, and reckon that it takes 5 years the first time, two the second! Part of the difficulty is in making sure it looks OK at all screen resolutions and in all supported versions of Windows.

Typing data into a table ought to be much easier, and would be if %lv actually worked as it is supposed to in Windows 7. Operating with a file of data that is already prepared and checked to be error free takes away many of the problems.

E

[JohnCampbell]

Eddie,

I don't use clearwin+ often enough, then forget what I did the last time.
I try to improve the documentation each time I go back to the code.

John

[LitusSaxonicum]

Further suggestions from me:

1. As most WINIO@ calls appear for your main window, divide the creation of that into subroutines for (a) standard window arrangements, font, background colour etc, (this can then be called for every subsidiary window), (b) menus - could even be more than one routine if menus are elaborate of dynamic), (c) toolbar - again, more than one routine if you have complex toolbars, or user-configurable styles, (d) rest of the window (which in my case is a big %gr area).
2. Put only one %?? format code per statement (simplifies editing the code during development, especially if you are so geriatric that you stick to card image 72 column format like me). Exceptions include %nl, %ta and %ff
3. If dividing your main window setup into routines, you may need an explicit SAVE for each routine to resolve close down problems.
4 .Use the XP style manifest whatever that is) by putting 1 24 default.manifest in your RESOURCES
5. Use lots of comments to stop you forgetting what the format codes do.
6. Before you even start coding, sketch up what you want your application to look like, and what you want the controls to do.
7. Read the User Interface Visual Guidelines on MSDN, so your windows look modern.
8. Look at other Windows applications to see what you like and what you don't.
9. Read not only FTN95.chm, but also the ENH file installed when you set up FTN95, and the PDF files for Clearwin and FTN77 library functions on this website.

E

[jjgermis]

Mike (Eddie and John as well)

I know this problem as well - I also agree that ClearWin+ is a good option. This is what I did

Learning ClearWin from the online Help will take a while - it has many bits and pieces.

My suggestions still is to have a complete application that explains all the steps on how to set-up the program through installing it.

Mike, Eddie once gave me an excellent example on how to do it. It took me a weekend to work through his "tutorial" - I still use it as a reference when I forget some stuff.

[LitusSaxonicum]

So if you want a copy, please send me an email via 'private message' so I know where to send it.

Look at the examples posted by Jalih.

Eddie

[jjgermis]

Hi Eddie,

thanks for the tip!

The example from jalih is worthwhile looking at. And this is what it looks like: