Silverfrost PE and Visual Studio 2010

Hello,

I have recently been tasked with a rather large project of updating and old FTN95 console application to a nice GUI application.

So I ended up coming across Silverfrost, which has been quite lovely overall (I am evaluating it to see if we will purchase it), however I am using the PE with Visual Studio 2010 and have noticed some oddness, for example when adding certain references Visual Studio will crash out silently and I have to manually add the reference to the project file using a text edtior, same thing when removing files from the project, when i try to they remain in the project file even though the file is no longer present on disk and I have to manually remove them from the project file with a text editor.

One other thing that I found quite inconvieniant is if I forget to add a reference to a library used by another library the compiler does not detect this and simply crashes and after analysing the log file only states 'Internal compiler error'.

So I am wondering if there is a way to fix issues like this, or if there is an update that will fix these issues before I commit to this software.

Thanks, Alex.

If you are not using .NET then the Plato IDE may work better for you.

Unfortunatley I am using .Net heavily, is there anything else I can do?

Alex,

Several of us on this forum don't use .NET, but manage to get all of the Windows interfacing done exclusively in Clearwin ... some correspondents use OpenGL, but I have never found the need for it (and, for that matter, I can't fathom out the intricacies of .NET either!). Moreover, some of us aren't particularly well-suited by Plato (and therefore wouldn't be suited by Visual Studio either), and make do with a simple text editor (the one I use has easy access to the command prompt) together with a handful of batch files. I have to admit that I didn't get on with the idea of a 'project file' either. As for Visual Studio 'crashing out', are you sure that it is FTN95 at fault, and not VS?

Surely, however, the matter of listing libraries and dependencies is a one-off job and not something you need to do repeatedly each time you sit down at the computer?

When you say an 'old FTN95 ...' I am assuming it is an 'old Fortran' console application, not something written specifically to suit Salford or Silverfrost FTN95. The excellent compiler diagostics and the speed of compilation of FTN95 should, at the very least, enable you to check that the old code compiles and runs properly before you start modifying it.

Those 'old Fortran' applications usually read their data from a datafile, and write their answers to another.

I have found the steps to integrating an old Fortran program into a GUI are:

(a) Write the GUI to put its data into a datafile in the format the old Fortran console app wants. (b) Write the back end of the GUI (the results presentation bit) to pick up the info written out to a file by the console app. (c) When (a) and (b) are working, get the console app launched by the GUI (say with START_PROCESS@) (d) Then turn the console app into a subroutine, which can be CALLed - but which still communicates by means of files. (e) Consider whether it is worth skipping the file writing business ... files write quickly on a modern PC, and short ones written and read soon afterwards are probably still in the disk cache so read very fast - and just pass the data over.

Obviously, it pays to write the GUI with a similar data storage strategy to the console app to facilitate the final step.

Depending on how old the console app is, you may be astonished to see how little space it takes up in RAM, and therefore how much you have free to play with.

Eddie

Yeah I am sure it is FTN95, but as you said, the things it crashes on are things I don't have to do very regulary, just sometimes when im writing a unit test or something.

Yeah this console application reads in a massive XML file and parses it for parameters, I just want to avoid this step of having to write and XML file as it will make it easier to change the data structure in the future, as parsing the XML file in FORTRAN code is a really robust process.

So my design stratergy is pretty much, re-scale the FORTRAN project as a .net assembly, send in the XML file as a object through the routines paramaters (I also created .Net wrapper classes for objects and arrays which allows both to be dealt with pretty well in FORTRAN), the FORTRAN parses this object, and fills another one with the results, .Net then has the results in memory and can do what it pleases with them... for example it could save it to a file or it could modify the output and run it through the simulation again.

The other benifit im getting from converting the console application to a .Net assembly is using my .Net helper classes I am able to throw exceptions with detailed messages straight back to th GUI rather then attaching to the consoles process.

Thanks, Alex.

Dear Alex,

I completely agree with your strategy of re-scaling FORTRAN projects as .net assemblies! That's exactly what I'm doing!

Unfortunately I've experienced a lot of problems (and crashes) in using FTN95 in VS2010, especially with references. Even if the recent service pack 1 has mitigated these problems, I solved all my troubles downgrading to visual studio 2008.

Good luck!

Emanuele

Quoted from Emanuele Dear Alex,

I completely agree with your strategy of re-scaling FORTRAN projects as .net assemblies! That's exactly what I'm doing!

Unfortunately I've experienced a lot of problems (and crashes) in using FTN95 in VS2010, especially with references. Even if the recent service pack 1 has mitigated these problems, I solved all my troubles downgrading to visual studio 2008.

Good luck!

Emanuele

Thanks, I keep running into small issues and I do believe there could be some serious enhancment to the visual studio 2010 integration.