Board index » kylix » Actual Cross-Platform Development

2005-08-01 04:56:35 AM
kylix2
I've seen quite a bit of general discussion here about what the best
cross-platform development tool to use is, but little about actual
cross-platform development (e.g., case studies). I've tried out a number
of cross-platform tools over the years and would like to relate my
experiences with some of them and how well they meet my goals of
preserving my huge investment in legacy Delphi code:
(1) Java - requires complete rewrite of all Delphi code.
(2) Kylix - let's face, Kylix is dead, and even if it weren't, it's not
truly cross-platform since there's no support for the most popular Unix
platform in use today, Mac OS X.
(3) Chrome - I have not been able to get even the simplest Chrome or
VB.NET Windows.Forms application to run under Mono on the Mac. I'm tired
of crossing my fingers waiting for things to get fixed (see 2 above).
Chrome is also different enough from Delphi in some fundamental ways that
it's difficult to move much legacy code from Delphi to Chrome. Example:
Chrome strings are 0-based, Delphi strings are 1-based. Any use of System
unit routines like Pos, Delete, Insert or Copy or indexing of string
chararacters (string[ ]) will have to be rewritten. In one of my projects,
I had over 500 uses of just these four routines alone. Hacking the code at
this level is a good way of introducing bugs into perfectly stable code.
(4) Free Pascal / Lazarus - this is the closest thing to the holy grail
that I've found yet. I was able to convert a modest-sized GUI app (approx.
6,000 lines of code) to Lazarus without much trouble and only a bit more
work to get it to compile and run on a Mac. I now have a single set of
source files that can be compiled with Delphi 7 or Lazarus on Win32 or
with Lazarus on Mac OS X and Linux.
I was also able to compile and test approx 50,000 lines of non-GUI code
with FPC on both Win32 and OS X with only minimal changes.
Ideally, cross-platform development should be planned for in the initial
program design and not added later to an existing code base, but even if
this wasn't planned for, it's not impossible to add it with Lazarus,
assuming the app was structured properly in the first place. That is, that
non-GUI number-crunching and database management code is in separate units
from GUI code and that Win32 API references have been isolated from the
rest of the code as well.
One advantage of Lazarus/FPC is that it has almost complete cross-platform
support for Delphi-compatible units such System, SysUtils, DateUtils,
StrUtils, Classes, Variants, Math, IniFiles, and Registry. It also has
incomplete cross-platform support for Windows and Messages units in the
form of its own LclIntf and LMessages units. The FPC compiler is also
highly compatible with Delphi code, requiring only a couple of minor
tweaks with var parameters where FPC is more restrictive than Delphi.
I've reported a few minor bugs to both the Free Pascal and Lazarus teams
within the last couple weeks and some of these have already been fixed in
the latest snapshots (www.ca.freepascal.org/Lazarus/). This may be
"beta" software in some sense, but it feels stable and alive.
My modest-sized app above exercised a number of things:
- VCL-type form and controls.
- Windows version resource (on the Mac, I just substituted an .ini file
containing the [Version Info Keys] entries from my project's .dof file
since this type of resource is specific to Window; I then loaded the file
with a TIniFile).
- Registry (on the Mac an .xml file can be used - your code stays the same
whether manipulating the Windows registry or an .xml file).
- dBASE file manipulation (on the Mac, a few conditionaly-compiled tweaks
to reverse the order of bytes in the binary values of a dBASE file's
header is all it tool to support this unit of mine on the Mac's
"big-endian" PowerPC processor).
This is not to say the FPC/Lazarus can be substituted in all cases for
Delphi. A couple of things that aren't currently supported could create
problems:
- No cross-platform help solution yet.
- No support for TRichEdit in the Laz ComCtrls unit.
Deployment of compiled GUI apps on Unix systems requires the GIMP Toolkit
(GTK) files to be installed. On Mac, the optional OS X X11 app also needs
to be installed as well. Currently, Laz apps on Mac use the GTK-based
controls, which may not be acceptable to some Mac users who don't want to
see the X11 menu and window on their desktop when running your app. But
for developers who would rather have a Mac-based app, X11 and GTK and all,
rather than no Mac app at all, this is an acceptable solution.
"Carbon"-based native Mac controls are planned, but little work has been
done on this to date.
--- posted by geoForum on delphi.newswhat.com
 

Couldn't you substitute Synedit for Trichedit?

I also tried the latest version and it's not bad at all, it even has
some refactoring support.
In reality everyone should drop doing all this kylix work and start
working on Lazarus :-)

{smallsort}

than display it as a formatted document the way TRichEdit and Word do?
The reason why TRichEdit is not implemented in Lazarus is because in
Delphi it's just a wrapper around the Windows RICHED32.DLL. Duplicating
the functionality of RICHED32.DLL in a platform-independent way would not
be easy.
Actually, the goal would be to duplicate the functionality of
RICHED20.DLL, which is the control for Rich Edit Control 3. I had to hack
the Delphi ComCtrls.pas just to activate support for RICHED20.DLL and
enable the advanced typography of Rich Edit 3 - would have been nice if
Borland had done this for us.
--- posted by geoForum on delphi.newswhat.com
 

As far as I know Synedit does not use richtext, but it's own format.
as far as I can tell, I can do everything I could do in trichedit with
tsynedit. What exactly are you doing with trichedit?

On 2005-07-31, WinPgmr-MacUser < XXXX@XXXXX.COM >wrote:
 

I'm using the TRichEdit control to display reports that have been
generated as .rtf files. TRichEdit can display fairly simple .rtf files
almost exactly the way Word does. A very nice control for embedding in a form.
TRichEdit does not show the raw RTF control words (e.g., \b Total \b0),
but the formatted RTF (e.g., Total - in bold).
 

Contact wptools or trichview for an open source contribution maybe?
"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message

Have WPTools or TRichView been ported to Lazarus / platform independent?
 

All I know is they don't depend on the ms rtf control, but handle rtf just
as well. Not sure how pure the rtf engines are with regard to delphi.
"WinPgmr-MacUser" < XXXX@XXXXX.COM >wrote in message

On Mon, 01 Aug 2005 23:21:00 -0500
tony < XXXX@XXXXX.COM >wrote:
Micha
 

justification are not supported AFAIK. It is more a programmer's editor
component, than a "Word"-like editor component.
Delphi's TRichEdit is.
Here's a comment from Lazarus's SynEditExport.pas:
"Base class for exporting a programming language source file or part of it
to a formatted output like HTML or RTF."
TRichEdit is a control for editing formatted (not syntax highlighted) RTF.
--- posted by geoForum on delphi.newswhat.com
 

WinPgmr-MacUser wrote:
I would like to see some shots of a large app running under Lazarus.
Another thing they need badly is packages so you don't have to
recompile the whole works to install third party components.
--
 

tony wrote:
.NET to Lazarus.
magnifier.sourceforge.net/
"Virtual Magnifying Glass is a free, open source, screen magnification
tool for Windows and Linux. It is simple, customizable, and easy-to-use."
You can see not only the screenshot, as well as download binaries and
download the source code.
experimental yet. It should arrive on Lazarus IDE on some months.
If you really need it you can always contribute =)
Felipe