Part Four: In Over My Head
Sorry to disappoint, but no database regression testing yet. Other Important Things have intruded. However, here is another batch of notes that I've collected. I hope that they are somewhat useful.FORMS
One very important note. Kylix can read .dfm files, but if you make changes and save them to the .dfm file, the .dfm file does not always work in Delphi 5.
In response to my questions regarding this, I got the following from Jörg Weingarten:
> Kylix can read Delphi 5 forms.One thing I noted when porting forms to Kylix is that one must pay attention to the PixelPerInch property on the form. My Delphi forms use 96ppi, while my X server is currently running at 75ppi. If you set the Scaled property to False and then back to True, it'll automatically pick up the new value.Yes, read and write. The issue you will run into is that the code parser will automatically update your code in places like the Uses clause. E.g. a "uses buttons" will be replaced by "uses QButtons". If you want to compile a Delphi 5 form under Kylix you also will most likely run into case sensitivity filename problems.
a. {$R *.DFM} has to be replaced by {$R *.dfm}. Delphi 5 saves the dfm file with a lower case extension. Kylix is case sensitive and will look for a DFM since the $R refers to that file
b. Unit name itself and actual filename might give you problems. If you never paid attention to what the actual filename is and what the Unit clause says you will get a compile error in Kylix.Other then that if you open a Delphi 5 form you will get told about every property, method, component that Kylix can't deal with. E.g. if the Delphi 5 DFM has a setting 'DragKind' set Kylix will tell you that this property does not exist and it will remove the setting from your DFM file if you save it. Now going back to Delphi 5 means you will not have that setting any longer.
> I'm getting conflicting stories on whether the .dfm
> files will work in D5 after being modified by Kylix.So from the above you see that they will work but you have to limit your Delphi 5 VCL programming to use only what Clx in Kylix provides you. So a 'sometimes' can be seen as a correct answer as well ... :-)
If you don't change the PixelsPerInch property, the components may look correct on the form at design time, but when you run the application you'll note that the controls are smaller. They'll be correctly positioned relative to one another, but the fonts and dimensions will be smaller. However the form size will not necessarily change so you may end up with a large border on the right and bottom.
VISUAL CONTROLS
I've not done a complete survey of the components, but a few things
are worth noting.
TComboBox's OnChange event has a little different behaviour. If you set Style to csDropDownList, the OnChange event will not fire as it does in Delphi 5. Use the OnClick event instead.
A minor difference is that when the ComboBox is selected but not "dropped down" one can use the arrow keys to move to the previous/next item as in Windows. An interesting thing is that the selections wrap around, taking you from the first to the last or vice versa. It's no big deal, and I actually kind of like it.
There is a confirmed bug in TMemo that few should have to worry about. Mark Duncan of Kylix R&D wrote:
This is a bug in the display of the underlying Qt QMultiLineEdit control (or more likely, the QTableView ancestor). It's in our bug database and AFAIK TrollTech has been informed.One strange instance of umlauts not working correctly in TLabel. Christian Kirsch wrote:
BTW the magic number on Linux is 4781, on Windows somewhat larger (~ 7000).
Since nobody else experienced this problem, I tried again today, changing back ue/ae to ü/ä -- no trouble this time. Let's call it a "once in a while"-problem.OBJECT PASCAL
There are new "hint" compiler directives for declarations:
- platform
- deprecated
- library
EStackOverflow = class(EExternal)
end deprecated;
According to the OP Language Guide, these will generates hints and/or warnings when hints and warnings are turned on. and you try use one of these marked classes.
- "platform" is for platform-specific items (Win32 vs. Linux).
- "deprecated" is for, well, deprecated items. (You shouldn't depend on being in the future releases.)
- "library" for library-specific items (VCL vs. CLX)
Stuff in Consts seems to now be in RTLConsts.
If I've never felt dumb before, I do now. I just learned that OP (at least since Delphi 2, probably earlier) allow non-local variables to be initialized like constants. I don't know how long this as been an OP feature. Leave it to me to not discover something that probably existed since the Turbo Pascal days! So much for thinking that I knew OP inside and out.
var
NonLocalVariable :Integer = 32;
IN-LINE ASSEMBLER
For the doomsayers, here's as close to disaster as I've come. You'll
be disappointed. <g>
I just pulled up a unit with a bunch of freebie assembly code that I got off the 'Net a few months ago. This stuff will have to be tweaked because it accesses unit-global variables in the "implementation" section. In actuality, the code kind of sucks from an object-oriented viewpoint, but it was freely available and is very fast.
Here is a difference between Win32 and Linux. Linux shared objects (DLL equivalents) require code to be "position independent," meaning that the code must be able to reside anywhere within virtual memory. You'll occationally see references to "PIC" (position-independent code) when working with Linux. (Not often, but occationally.) The main difference is that instead of accessing memory directly, e.g.
MOV EAX,VarName
one must do it relative to a base address. Linux uses the EBX register, which must be preserved through calls. This means that in Kylix the sample code must be changed to
MOV EAX,[EBX].VarName
(Anybody remember doing assembly programming the Amiga? All library calls were done relative to base addresss, but having the MC680x0 architecture meant that one had 15 general-purpose registers to play with so it was never a problem, but a nice feature.)
OK, I revise my previous statement. After working with it for a while, this code really sucks from a cross-platform point of view. It's not the authors' fault. The authors really spent a lot of time optimizing the code for use in DOS. The code was later ported to 32-bit Delphi. PIC wasn't a factor when this code was written.
The problem is that when you're squeezing the most out of the available registers, adding one more thing to track (the base address) becomes highly painful. This code will be too much of a bother to update. If I had to point to the problem, IMHO it's the fact that the Intel IA32 architecture (80x86) skimped on registers, so we'll have to live with it. (IA32 unfortunately is still blinded by its 4-bit roots.)
On a different issue, the in-line assembler is a little more pedantic.
BSWAP BX must be changed to BSWAP EBX. Technically the first shouldn't have compiled at all in the Delphi 5 in-line assembler, but I never noticed the typo until Kylix caught it. (Hey, it ran correctly!)
COMPILER
Kylix seems to be more aggressive with "Variable 'X' might not have been initialized" warnings. This is cropping up with code that compiles without warnings under Delphi 5. This seems to happen when there is an "if Y then Exit" statement before variable X is used. The variable is never initialized, but neither is it ever used. I got confirmation that the warning is inappropriate.
This type of code compiles without warnings in Delphi 5, but with a warning in Kylix.
procedure TMyObject.A;
var
x :Integer;
begin
if not IsValid then Exit;
x := blah;
// etc.
end;
Also, typed constants will no longer be writable by default. Danny Thorpe wrote
>Thats a pascal compiler option. By default, intialized consts are in fact
>assignable. Its a Pascal "Quirk".Not in Kylix, it's not. The compiler default is typed consts are read-only. It will be off by default in Delphi 6 as well.
DATABASE
Chris Pattinson generously supplied the following:
For your database question, go with these components and set these properties (Vbasic and for simple connection):
//note:assumes Interbase installed , and not going into much detail on defining IBConnectionTSQLConnection (ConnectionName=IBConnection) //example: set
Database=/opt/interbase/examples/employee.gdb
TSQLTable (SQLConnection=SQLConnection1, TableName=IBTable) //such as EMPLOYEE
TDataSetProvider(DataSet=SQLTable)
TClientDataSet(ProviderName=DataSetProvider1, Active=True)//if all is well, active will set to true and no error message. That means you got it right!
TDataSource (DataSet=ClientDataSet1)
TDBGrid(DataSource=DataSource1)The DataSetProvider is the Midas layer that enables 2 way connection and bufferithe data before doing a commit. (ClientDataSet.Applyupdates(-1) for instance). These out.
Also TSQLClientDataSet is a nifty little component you might want to read up on
help since it handles the work of three components so you can just drop it and adatasource, then to dbgrid. Has some limitations though- not recommended for
master/detail or complex relationships (will go much slower then the normal
ClientDataSet).
LEARNING LINUX PROGRAMMING
One question that I've been getting is "I have lots of books on Windows internals. How can I learn how to program Linux?" There are many excelent books. My favourite is Beginning Linux Programming by Matthews & Stones, published by WROX. This as been described as a "quick walk" around Linux. It's not the "Linux Bible" by any stretch of the imagination. Other people don't really care for the book, so YMMV.
John Shemitz expressed his opinion on the ngs,
Johnson & Troan "Linux Application Development" is a better book, imho, but still not the API "bible" you were looking for.One thing most everybody can agree on is that O'Reilly books are the de facto standard place to look for Un*x reference materials. They address individual topics in great depth. One may find their books at any decent bookstore. Linux-specific books can be found here, but remember that just about any Un*x-related topic fits in just as well.
On the neglected topics is the underlying philosophy on Un*x. ESR, one of the notable personages in the Un*x world, has a work in progress at http://www.tuxedo.org/~esr/writings/taoup/ -- finally I understand why I occationally approach application design in such an unorthodox manner (from the Windows perspective). Thanks, Eric!
Version History:
2001-03-17:
Created document
