VPP Catamaran

[Leo Lazauskas]

Originally Posted by Tim B

What are you writing the interface in, Leo?

My experiences with writing GUIs have been good so far with QT. Small, light and multi-platform.

Tim B.

Thanks, Tim.

I tried wxWindows about 4 years ago. It has very slow and still buggy. I'm sure that it, and QT, and many others have improved since then, but I've lost interest in the GUI side of programming.

One day I might try to hack into FreeShip and see if I can launch other programs from inside it. All I want is to be able to write a text file of hull offsets and maybe some other variables, launch a batch file that executes some hydrodynamic codes and then writes a text file that FreeShip can read and interpret. That's about the extent of what I plan do with GUI programming.

Leo.

[tspeer]

FWIW, if a code is written to support Object Linking and Embedding, and its functions are documented, then you can call the functions from Excel. This gives you a ready-made user interface with a great deal of flexibility. And Excel has all the widgets for building a sophisticated GUI. I've gone this way with calling Multisurf from Excel, and it works a treat.

The same thing holds for compiling the program's guts as a DLL. They can be called from VBA routines within Excel.

In addition to Godzilla, linking an analysis program to Excel allows you to use Excel's solver to turn it into a hybrid design code. The only restriction is all the inputs and outputs have to be located on one Excel worksheet.

I typically prepare Michlet input decks using Excel anyway, and output them as a text file for Michlet to read. Not as smooth as a direct interface, but it gets the job done.

[Tim B]

Using Excel for a front-end is an adequate, but not good, way of producing a GUI. Initially you tie yourself to proprietry software. Secondly, you find that in the time it takes to do use Excel is just as long as writing it yourself. Thirdly, there is no possibility of porting to another OS.

Personally, I think that a spreadsheet should be a spreadsheet. It is a way of quickly organising, manipulating and plotting data. It is not a solution for complex systems which would be better written as code, in whatever language you prefer. There are far too many engineers who have learnt to use excel (in some depth) rather than learning a programming language.

I now don't support any of my own code on Windows, though a lot of what I've written can be re-compiled on Win32/64. All my code is written for Linux, then ported else-where if needed. You could argue about the benefits of Linux over Windows for months, but given that there is a growing Linux community, and that by comparison Windows (XP & Vista) are very poor products, I think I've arrived at a very reasonable solution.

[Leo Lazauskas]

Originally Posted by Tim B

Using Excel for a front-end is an adequate, but not good, way of producing a GUI. Initially you tie yourself to proprietry software. Secondly, you find that in the time it takes to do use Excel is just as long as writing it yourself. Thirdly, there is no possibility of porting to another OS.

I tried that path myself a while ago. I also tried writing a dll for MathCad. It worked Ok with a small number of offsets, but laboured with more. I was also put off by the thought of tying the code to someone else's code over which I had almost no control.

[Dusan]

Does anybody know where I can find some more detail information about the power catamaran stabillity and resistance?