Making Firemonkey more compatible with Delphi

I have programmed in Delphi since 1995 Delphi1

I am now evaluating Delphi XE4.

It boggles my mind, why embarcadero has lost the most important aspects of Delphi.

Simplicity and Fast User Interface creation.

I can easily see how Firemonkey can be improved to bring it in line with traditional Delphi Techniques by doing the following.


1. All Firemonkey controls need a data aware counterpart.
2. Firemonkey Styles need to be converted to TControl descendants.
3. ie. TLayout goes to TPanel ( TFMXPanel )
4. ie. TRectangle does to TFrame  TFMXFrame )
5. LiveBindings gets placed underneath ( TFMXDataSource )
6. Style Editor becomes a simple FMX Editor.

Unless this is done, I cannot see how XE4 can really take off as a product

Kind Regards,

Robert.
0
Robert
7/10/2013 4:29:54 AM
embarcadero.delphi.non-tech 5933 articles. 1 followers. Follow

43 Replies
2864 Views

Similar Articles

[PageSpeed] 48

Robert Gilland wrote:

> 1. All Firemonkey controls need a data aware counterpart.

> 5. LiveBindings gets placed underneath ( TFMXDataSource )

It seems you've missed the point of LiveBindings

-- 
Dave Nottage [TeamB]
0
Dave
7/10/2013 4:43:27 AM
Robert Gilland wrote:

> I have programmed in Delphi since 1995 Delphi1
> 
> I am now evaluating Delphi XE4.
> 
> It boggles my mind, why embarcadero has lost the most important
> aspects of Delphi.
> 
> Simplicity and Fast User Interface creation.
> 
> I can easily see how Firemonkey can be improved to bring it in line
> with traditional Delphi Techniques by doing the following.
> 
> 
> 1. All Firemonkey controls need a data aware counterpart.
> 2. Firemonkey Styles need to be converted to TControl descendants.
> 3. ie. TLayout goes to TPanel ( TFMXPanel )
> 4. ie. TRectangle does to TFrame  TFMXFrame )
> 5. LiveBindings gets placed underneath ( TFMXDataSource )
> 6. Style Editor becomes a simple FMX Editor.
> 
> Unless this is done, I cannot see how XE4 can really take off as a
> product
> 
> Kind Regards,
> 
> Robert.

Same feelings here. The quality of Firemonkey has not been good since
the first release. No joy. EMBT need to act on this as a top priority!


-- 
Steve Faleiro
0
Steve
7/10/2013 4:44:28 AM
On Tue, 9 Jul 2013 21:43:27 -0700, Dave Nottage <"Dave Nottage (TeamB)" <>> wrote:

>Robert Gilland wrote:
>
>> 1. All Firemonkey controls need a data aware counterpart.
>
>> 5. LiveBindings gets placed underneath ( TFMXDataSource )
>
>It seems you've missed the point of LiveBindings

I guess one of the points is to make porting of existing data-ware based apps to FM harder and also to make resulting LB-based apps work
slower than their db-aware counterparts? ;)

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/10/2013 8:31:49 AM
> 1. All Firemonkey controls need a data aware counterpart.

That's what LiveBindings are for, not that I like the LB code, though I'm not overly keen on the old DB controls code either.

> 2. Firemonkey Styles need to be converted to TControl descendants.

Why? They are composed of (FMX) TControl descendants.

> 3. ie. TLayout goes to TPanel ( TFMXPanel )

Again, why? It works fine as it is, and in fact works marginally better than in the VCL. There's also a FMX TPanel if you want a simple styled container.

> 4. ie. TRectangle does to TFrame  TFMXFrame )

TRectangle and TFrame are completely different, and anyhow, FMX has a TFrame implementation now.

> 5. LiveBindings gets placed underneath ( TFMXDataSource )

LiveBindings work upon a TDataSource - they aren't an alternative.

> 6. Style Editor becomes a simple FMX Editor.

The IDE's style editor is crap for sure, though FMX styles could do with a bit of rethinking generally.

> Unless this is done, I cannot see how XE4 can really take off as a product

Far more important are the performance issues where they exist.
0
Chris
7/10/2013 8:43:23 AM
Robert Gilland wrote:
<something about turning Firemonkey into standard VCL>

No, I think the current FMX class structure is pretty OK. The GUI
designer, however, should evolve with it, and not remain the form on
which you plaster some components. Like we did in 1995.
0
Dominique
7/10/2013 11:00:43 AM
Vladimir Ulchenko wrote:

> I guess one of the points is to make porting of existing data-ware based apps to FM harder and also to make resulting
> LB-based apps work slower than their db-aware counterparts? ;)

The point of LiveBindings is to make it easier to bind *anything* to datasets.

-- 
Dave Nottage [TeamB]
0
Dave
7/10/2013 11:46:33 AM
On Wed, 10 Jul 2013 04:46:33 -0700, Dave Nottage <"Dave Nottage (TeamB)" <>> wrote:

>The point of LiveBindings is to make it easier to bind *anything* to datasets.

for someone trying to bring his existing VCL app heavily relying on db-aware components I don't quite understand how LB alone (without
vendor support) can make his life easier if there are no corresponding counterparts among FM components. moreover afaik performance of
resulting LB solution isn't on par with traditional VCL dataaware approach

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/10/2013 12:22:52 PM
Vladimir Ulchenko wrote:

> for someone trying to bring his existing VCL app heavily relying on db-aware components I don't quite understand how
> LB alone (without vendor support) can make his life easier if there are no corresponding counterparts among FM
> components.

Good thing I didn't say that it would, then.

-- 
Dave Nottage [TeamB]
0
Dave
7/10/2013 5:23:36 PM
Robert Gilland wrote:

> I can easily see how Firemonkey can be improved to bring it in line
> with traditional Delphi Techniques by doing the following.

ISTM You don't want to make it more compatible with Delphi, you want to
make it more like the VCL.

-- 
Rudy Velthuis (TeamB)    http://www.teamb.com

"Real Programmers never work from 9 to 5. If any real programmer
 is around at 9 a.m., it's because they were up all night."
 -- Some Computer Geek
0
Rudy
7/10/2013 7:46:32 PM
Am 10.07.2013 06:44, schrieb Steve Faleiro:
> Robert Gilland wrote:
> 
>> I have programmed in Delphi since 1995 Delphi1
>>
>> I am now evaluating Delphi XE4.
>>
>> It boggles my mind, why embarcadero has lost the most important
>> aspects of Delphi.
>>
>> Simplicity and Fast User Interface creation.
>>
>> I can easily see how Firemonkey can be improved to bring it in line
>> with traditional Delphi Techniques by doing the following.
>>
>>
>> 1. All Firemonkey controls need a data aware counterpart.
>> 2. Firemonkey Styles need to be converted to TControl descendants.
>> 3. ie. TLayout goes to TPanel ( TFMXPanel )
>> 4. ie. TRectangle does to TFrame  TFMXFrame )
>> 5. LiveBindings gets placed underneath ( TFMXDataSource )
>> 6. Style Editor becomes a simple FMX Editor.
>>
>> Unless this is done, I cannot see how XE4 can really take off as a
>> product
>>
>> Kind Regards,
>>
>> Robert.
> 
> Same feelings here. The quality of Firemonkey has not been good since
> the first release. No joy. EMBT need to act on this as a top priority!
> 

They know this. Issue is, that they also know they need to cover
additional plattforms.

And I do not think all controls need a data aware counterpart. That's
what LiveBindings are fore! (even if their implementation might not be
what many of us want technology wise, but that's something different).
LiveBindings are more flexible.

And why do all styles need to be converted to TControl descendants? WHat
value does this bring to me? There are a few issues I guess, but I'm not
sure that's an important one. Better spend the time for further bug fixing.

Greetings

Markus
0
Markus
7/10/2013 8:33:54 PM
> {quote:title=Dave Nottage wrote:}{quote}
> Vladimir Ulchenko wrote:
> 
> > I guess one of the points is to make porting of existing data-ware based apps to FM harder and also to make resulting
> > LB-based apps work slower than their db-aware counterparts? ;)
> 
> The point of LiveBindings is to make it easier to bind *anything* to datasets.
> 
> -- 
> Dave Nottage [TeamB]

Thanks Dave for being specific about the point of "LiveBindings"

It is this point I question.

LiveBindings was created BECAUSE Firemonkey was supposedly incompatible with data aware controls.

And Thus the "anything" you refer to is actually Firemonkey itself.

If on the other hand the effort was put into making shelter data aware components for Firemonkey.

Then Delphi would not have lost it's great advantages in user interface design, which it has now.

We are on the edge of rejecting XE4 for our mobile apps and moving to "eclipse".

I remind you that I am probably one of Delphi's most stoic supporters in Australia.

As mobile apps are becoming the way of the future.

It would sadden me that my company which I am head developer of would have to move away from Delphi.

Kind Regards,

Robert
0
Robert
7/10/2013 10:47:47 PM
Robert Gilland wrote:

> LiveBindings was created BECAUSE Firemonkey was supposedly incompatible with data aware controls.

Data aware controls prior to Firemonkey were VCL controls, with data-aware support added. It would have been enitrely
possible to do the same with Firemonkey controls. LiveBindings removes the need to do so.

> And Thus the "anything" you refer to is actually Firemonkey itself.

No, you can bind to VCL controls, too.

> I remind you that I am probably one of Delphi's most stoic supporters in Australia.

Great to hear; you're likely to have your information correct, then.

-- 
Dave Nottage [TeamB]
0
Dave
7/10/2013 11:06:38 PM
> 
> > And Thus the "anything" you refer to is actually Firemonkey itself.
> 
> No, you can bind to VCL controls, too.
> 

What I am saying here is that without FireMonkey, LiveBindings would not have come into being.

Yes LiveBindings works with VCL as it should.

However if FireMonkey was implemented correctly, then LiveBindings would not be required.

I am just asking that Firemonkey be implemented seamlessly with traditional Delphi implementation.

My main angst is caused by me having to use "notepad" to create a TListBoxItem style.

It should never have come to this!

Wouldn't you say this is going backwards.

I used text editors to write UI in the early 90's.

Looks like I am going to have to do it again.

Kind Regards,

Robert.
0
Robert
7/10/2013 11:19:44 PM
> What I am saying here is that without FireMonkey, LiveBindings would not have come into being.

Not strictly true. LiveBindings were developed in house, FMX bought from outside (not that there's anything intrinsically wrong with that - so was the 32 bit compiler).

> However if FireMonkey was implemented correctly, then LiveBindings would not be required.

The LiveBindings approach was clearly taken deliberately (have you seen the reams and reams of code involved? it wasn't developed quickly), so the people who worked on it wouldn't agree.

> My main angst is caused by me having to use "notepad" to create a TListBoxItem style.

Out of interest, what's the scenario here - trying to mimic the custom list box style demo maybe? For myself, I always go back to a code-based approach, similar to what one would with the VCL.

> I used text editors to write UI in the early 90's.

Although, custom control writing in the VCL is all non-visual.
0
Chris
7/11/2013 7:42:39 AM
On Wed, 10 Jul 2013 13:33:54 -0700, Markus Humm <markus.humm@freenet.de> wrote:

>And I do not think all controls need a data aware counterpart. That's

but I do

>LiveBindings are more flexible.

.... slower and requiring adoption of new techniques and design

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/11/2013 7:43:37 AM
On Wed, 10 Jul 2013 10:23:36 -0700, Dave Nottage <"Dave Nottage (TeamB)" <>> wrote:

>Good thing I didn't say that it would, then.

maybe I misunderstood you but I somehow got the impression that by quoting the following

>Robert Gilland wrote:
>
>> 1. All Firemonkey controls need a data aware counterpart.

and answering with "It seems you've missed the point of LiveBindings"

you implied that Firemonkey doesn't need data aware components

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/11/2013 7:47:09 AM
> LiveBindings are more flexible.

Sure, but on the other hand are they really better than just having 
plain old code to "manually" bind everything?

The LB UI is arguably less convenient than the Delphi code editor, and 
they're more fragile to refactoring than code, and you can't find easily 
what is linked to what. Also they're runtime creatures that bomb at 
runtime in case of errors, there is no way to easily validate them (let 
alone test them), and debugging them is an horrible process even in 
simple cases.

So I would argue that you're better off just binding by plain old code 
(if your UIs are going to be statically compiled) or through scripts (if 
your UIs are dynamically designed), both for maintainance and in terms 
of the time it takes to set up things.

Eric
0
Eric
7/11/2013 7:58:14 AM
> So I would argue that you're better off just binding by plain old code
> (if your UIs are going to be statically compiled) or through scripts (if
> your UIs are dynamically designed), both for maintainance and in terms
> of the time it takes to set up things.


I think they should've introduces Datasource property to a base
VCL component and ignore it if not assigned and provided
some virtual dataset to be derived from and map user
structures to visual controls
0
Konstantine
7/11/2013 8:33:55 AM
On 2013-07-10 05:29, Robert Gilland wrote:
> 
> 1. All Firemonkey controls need a data aware counterpart.

That is such an "old school" way of doing data binding (right from
Visual Basic days). For years already I have implemented and used my own
data bindings (long before LiveBinding existed) by using the Mediator
and Observer design patterns. The thin layer of classes wrap existing
non-DB components (no descendant components are needed like the DB-aware
controls). A BIG plus is that this thin layer is 95% non-GUI so I can
use in with other GUI toolkits too, like Lazarus's LCL or fpGUI Toolkit.

Hooking up a component to data can be done visually in the Forms
Designer, or my preferred method of a single line of code. I have 2-way
updating/synchronization too. Not a single db-aware component in sight -
that goodness!


Regards,
  - Graeme -
0
Graeme
7/11/2013 8:49:32 AM
On Thu, 11 Jul 2013 00:58:14 -0700, Eric Grange <egrangeNO@SPAMglscene.org> wrote:

>Sure, but on the other hand are they really better than just having 
>plain old code to "manually" bind everything?
>
>The LB UI is arguably less convenient than the Delphi code editor, and 
>they're more fragile to refactoring than code, and you can't find easily 
>what is linked to what. Also they're runtime creatures that bomb at 
>runtime in case of errors, there is no way to easily validate them (let 
>alone test them), and debugging them is an horrible process even in 
>simple cases.

I believe someone in emb. just wanted to play with their new shining toy (enh. rtti?) without much care how that would fit the real-world
applications, typical problem with emb. "solutions"

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/11/2013 9:16:11 AM
Hi!

>> So I would argue that you're better off just binding by plain old code
>> (if your UIs are going to be statically compiled) or through scripts (if
>> your UIs are dynamically designed), both for maintainance and in terms
>> of the time it takes to set up things.
>
>I think they should've introduces Datasource property to a base
>VCL component and ignore it if not assigned

+1

I think that assigning a field to property would make sense. The field is 
linked
to dataset and separate property for dataset is not needed.

The concept of LiveBindings was copied from C#, but in C# you can edit the 
code created by
the visual editor. It is not stored in separate dfm, only separate source 
file.

Kind Regards!
Atmapuri
0
Janez
7/11/2013 9:36:28 AM
> The concept of LiveBindings was copied from C#, but in C# you can edit the
> code created by the visual editor. It is not stored in separate dfm,
 > only separate source file.

And that makes all the difference: it's source code, it's compilable, 
debuggable, etc.

Eric
0
Eric
7/11/2013 9:46:30 AM
On Thu, 11 Jul 2013 02:36:28 -0700, Janez Atmapuri Makovsek <janez.makovsek@usa.net> wrote:

>I think that assigning a field to property would make sense. The field is 
>linked
>to dataset and separate property for dataset is not needed.

actually that's not very good idea in some circumstances. once you delete bound dataset you'll lose bindings for all db-aware components
linked to that dataset. on the contrary one can freely re-link bound datasource to any dataset without loosing those bindings given that
typical db-aware component stores bound datasource and field _name_

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/11/2013 10:39:47 AM
> I believe someone in emb. just wanted to play with their new shining
> toy (enh. rtti?) without much care how that would fit the real-world
> applications, typical problem with emb. "solutions"

Think you hit the nail
0
Konstantine
7/11/2013 11:53:31 AM
> {quote:title=Graeme Geldenhuys wrote:}{quote}

> Hooking up a component to data can be done visually in the Forms
> Designer, or my preferred method of a single line of code. I have 2-way
> updating/synchronization too. Not a single db-aware component in sight -
> that goodness!


Just curious; Is this just an intermediate layer between tcomponent and tDatasource?
0
Arthur
7/11/2013 1:51:13 PM
On 2013-07-11 14:51, Arthur Hoornweg wrote:
> 
> 
> Just curious; Is this just an intermediate layer between tcomponent and tDatasource?

No. You can Google "Model GUI Mediator" (MGM) to get a better idea about
the design pattern. My implementation of MGM has evolved a lot since
around 2007 to now, and about 2-3 years ago it got even more simpler to
use and design time support was added for Delphi and Lazarus IDE's. All
the MGM code lives in the repository of the tiOPF project.



Regards,
  - Graeme -
0
Graeme
7/11/2013 7:07:44 PM
Hello,

I just don't understand what you have against a more flexible concept
where you can bind anything to anything and not only specifically
prepared and developed stuff.

Why to we need to recreate every standard control in a data control
fashion again? What's the added value in that? It will only lead to more
bugs due to more code.

Greetings

Markus
0
Markus
7/11/2013 9:29:51 PM
Am 11.07.2013 09:43, schrieb Vladimir Ulchenko:
> On Wed, 10 Jul 2013 13:33:54 -0700, Markus Humm <markus.humm@freenet.de> wrote:
> 
>> And I do not think all controls need a data aware counterpart. That's
> 
> but I do
> 
>> LiveBindings are more flexible.
> 
> ... slower and requiring adoption of new techniques and design
> 

So you're against it because it's a new concept?
(I can understand the "slower" issue but not the other)

Maybe LiveBindings are once changed (in a compatible way with today's
implementation) reducing those issues?

Data aware controls is just not the way to go. Too inflexible.

Greetings

Markus
0
Markus
7/11/2013 9:31:30 PM
> 
> Out of interest, what's the scenario here - trying to mimic the custom list box style demo maybe? For myself, I always go back to a code-based approach, similar to what one would with the VCL.
> 

Yes that is exactly what I have to do to be able to tell my boss that XE4 is a worthwhile dev environment for mobile.

Trying to build a Custom ListBoxItem style

I tried the code based approach option. Got stuck big time.

All I need is

ITEM DESCRIPTION
Det1    Det2      Det3
Det4    Det5      Det6



format in either code based approach ( couldn't get working ) or Custom Style approach( horrified at having to use notepad )

Kind Regards,

Robert.
0
Robert
7/11/2013 10:27:49 PM
> > Out of interest, what's the scenario here - trying to mimic the custom list box style demo maybe?
> > For myself, I always go back to a code-based approach, similar to what one would with the VCL.
> > 
> 
> Yes that is exactly what I have to do to be able to tell my boss that XE4 is a worthwhile dev environment for mobile.
> 
> Trying to build a Custom ListBoxItem style

So... because you are stuck on something impossible in a VCL context, FMX is bad because it doesn't blindly mimic the VCL...?

Anyhow, more constructively, what's the code you 'couldn't get working'?
0
Chris
7/11/2013 11:28:47 PM
> Anyhow, more constructively, what's the code you 'couldn't get working'?

OK, you asked for it. Here is my attempt at creating the following layout:

ITEM NAME
det1   det2  det3
det4   det5  det6

nothing went where i told it to go!

see below:

Kind Regards,

Robert.

unit ListItemDetailobjects;

interface

uses FMX.ListView, FMX.ListView.Types, System.Classes, System.SysUtils,
FMX.Types, System.UITypes;

type

  TStockTakeItemAppearanceNames = class
  public const
    ListItem = 'StockItem';
    ListItemCheck = ListItem + 'Edit';
    ListItemDelete = ListItem + 'Delete';
    Detail1 = 'det1';  // Name of MultiDetail object/data
    Detail2 = 'det2';
    Detail3 = 'det3';
    Detail4 = 'det4';
    Detail5 = 'det5';
    Detail6 = 'det6';
  end;

implementation

uses System.Math, System.Rtti;

type
  TStockTakeItemAppearance = class(TPresetItemObjects)
  public const
    cTextMarginAccessory = 8;
    cDefaultHeight = 80;
  private
    FMultiDetail1: TTextObjectAppearance;
    FMultiDetail2: TTextObjectAppearance;
    FMultiDetail3: TTextObjectAppearance;
    FMultiDetail4: TTextObjectAppearance;
    FMultiDetail5: TTextObjectAppearance;
    FMultiDetail6: TTextObjectAppearance;
    procedure SetMultiDetail1(const Value: TTextObjectAppearance);
    procedure SetMultiDetail2(const Value: TTextObjectAppearance);
    procedure SetMultiDetail3(const Value: TTextObjectAppearance);
    procedure SetMultiDetail4(const Value: TTextObjectAppearance);
    procedure SetMultiDetail5(const Value: TTextObjectAppearance);
    procedure SetMultiDetail6(const Value: TTextObjectAppearance);
  protected
    function DefaultHeight: Integer; override;
    procedure UpdateSizes; override;
    function GetGroupClass: TPresetItemObjects.TGroupClass; override;
    procedure SetObjectData(const AListViewItem: TListViewItem; const AIndex: string; const AValue: TValue; var AHandled: Boolean); override;
  public
    constructor Create; override;
    destructor Destroy; override;
  published
    property Image;
    property MultiDetail1: TTextObjectAppearance read FMultiDetail1 write SetMultiDetail1;
    property MultiDetail2: TTextObjectAppearance read FMultiDetail2 write SetMultiDetail2;
    property MultiDetail3: TTextObjectAppearance read FMultiDetail3 write SetMultiDetail3;
    property MultiDetail4: TTextObjectAppearance read FMultiDetail4 write SetMultiDetail4;
    property MultiDetail5: TTextObjectAppearance read FMultiDetail5 write SetMultiDetail5;
    property MultiDetail6: TTextObjectAppearance read FMultiDetail6 write SetMultiDetail6;
    property Accessory;
  end;

  TStockTakeItemDeleteAppearance = class(TStockTakeItemAppearance)
  private const
    cDefaultGlyph = TGlyphButtonType.Delete;
  public
    constructor Create; override;
  published
    property GlyphButton;
  end;

  TStockTakeItemShowCheckAppearance = class(TStockTakeItemAppearance)
  private const
    cDefaultGlyph = TGlyphButtonType.Checkbox;
  public
    constructor Create; override;
  published
    property GlyphButton;
  end;


const
  cMultiDetail1Member = 'Detail1';
  cMultiDetail2Member = 'Detail2';
  cMultiDetail3Member = 'Detail3';
  cMultiDetail4Member = 'Detail4';
  cMultiDetail5Member = 'Detail5';
  cMultiDetail6Member = 'Detail6';


constructor TStockTakeItemAppearance.Create;
begin
  inherited;
  Accessory.DefaultValues.AccessoryType := TAccessoryType.More;
  Accessory.DefaultValues.Visible := True;
  Accessory.RestoreDefaults;
  Text.DefaultValues.VertAlign := TListItemAlign.Leading;
  Text.DefaultValues.TextVertAlign := TTextAlign.taLeading;
  Text.DefaultValues.Height := 60;  // Item will be bottom aligned, with text top aligned
  Text.DefaultValues.Visible := True;
  Text.DefaultValues.WordWrap := True;
  Text.RestoreDefaults;

  FMultiDetail1 := TTextObjectAppearance.Create;
  FMultiDetail1.Name := TStockTakeItemAppearanceNames.Detail1;
  FMultiDetail1.DefaultValues.Assign(Text.DefaultValues);  // Start with same defaults as Text object
  FMultiDetail1.IsDetailText := TRUE;
//  FMultiDetail1.DefaultValues.Height := 56; // Move text down
  FMultiDetail1.PlaceOffset.X := 0;
  FMultiDetail1.PlaceOffset.Y := 30;
  FMultiDetail1.DefaultValues.IsDetailText := True; // Use detail font
  FMultiDetail1.RestoreDefaults;
  FMultiDetail1.OnChange := Self.ItemPropertyChange;
  FMultiDetail1.Owner := Self;

  FMultiDetail2 := TTextObjectAppearance.Create;
  FMultiDetail2.Name := TStockTakeItemAppearanceNames.Detail2;
  FMultiDetail2.DefaultValues.Assign(FMultiDetail1.DefaultValues);  // Start with same defaults as Text object
//  FMultiDetail2.DefaultValues.Height := 38; // Move text down
  FMultiDetail2.PlaceOffset.X := 0;
  FMultiDetail2.PlaceOffset.Y := 60;
  FMultiDetail2.IsDetailText := TRUE;
  FMultiDetail2.RestoreDefaults;
  FMultiDetail2.OnChange := Self.ItemPropertyChange;
  FMultiDetail2.Owner := Self;

  FMultiDetail3 := TTextObjectAppearance.Create;
  FMultiDetail3.Name := TStockTakeItemAppearanceNames.Detail3;
  FMultiDetail3.DefaultValues.Assign(FMultiDetail2.DefaultValues);  // Start with same defaults as Text object
//  FMultiDetail3.DefaultValues.Height := 20; // Move text down
  FMultiDetail3.PlaceOffset.X := 80;
  FMultiDetail3.PlaceOffset.Y := 0;
  FMultiDetail3.IsDetailText := TRUE;
  FMultiDetail3.RestoreDefaults;
  FMultiDetail3.OnChange := Self.ItemPropertyChange;
  FMultiDetail3.Owner := Self;

  FMultiDetail4 := TTextObjectAppearance.Create;
  FMultiDetail4.Name := TStockTakeItemAppearanceNames.Detail4;
  FMultiDetail4.DefaultValues.Assign(FMultiDetail1.DefaultValues);  // Start with same defaults as Text object
//  FMultiDetail4.DefaultValues.Height := 56; // Move text down
  FMultiDetail4.PlaceOffset.X := 80;
  FMultiDetail4.PlaceOffset.Y := 60;
  FMultiDetail4.RestoreDefaults;
  FMultiDetail4.OnChange := Self.ItemPropertyChange;
  FMultiDetail4.PlaceOffset.X := 100;
  FMultiDetail4.Owner := Self;

  FMultiDetail5 := TTextObjectAppearance.Create;
  FMultiDetail5.Name := TStockTakeItemAppearanceNames.Detail5;
  FMultiDetail5.DefaultValues.Assign(FMultiDetail1.DefaultValues);  // Start with same defaults as Text object
//  FMultiDetail5.DefaultValues.Height := 38; // Move text down
  FMultiDetail5.PlaceOffset.X := 160;
  FMultiDetail5.PlaceOffset.Y := 0;
  FMultiDetail5.RestoreDefaults;
  FMultiDetail5.OnChange := Self.ItemPropertyChange;
  FMultiDetail5.PlaceOffset.X := 100;
  FMultiDetail5.Owner := Self;

  FMultiDetail6 := TTextObjectAppearance.Create;
  FMultiDetail6.Name := TStockTakeItemAppearanceNames.Detail6;
  FMultiDetail6.DefaultValues.Assign(FMultiDetail1.DefaultValues);  // Start with same defaults as Text object
//  FMultiDetail6.DefaultValues.Height := 20; // Move text down
  FMultiDetail6.PlaceOffset.X := 160;
  FMultiDetail6.PlaceOffset.Y := 60;
  FMultiDetail6.RestoreDefaults;
  FMultiDetail6.OnChange := Self.ItemPropertyChange;
  FMultiDetail6.PlaceOffset.X := 100;
  FMultiDetail6.Owner := Self;

  // Define livebindings members that make up MultiDetail
  FMultiDetail1.DataMembers :=
    TObjectAppearance.TDataMembers.Create(
      TObjectAppearance.TDataMember.Create(
        cMultiDetail1Member, // Displayed by LiveBindings
        Format('Data["%s"]', [TStockTakeItemAppearanceNames.Detail1])));   // Expression to access value from TListViewItem
  FMultiDetail2.DataMembers :=
    TObjectAppearance.TDataMembers.Create(
      TObjectAppearance.TDataMember.Create(
        cMultiDetail2Member, // Displayed by LiveBindings
        Format('Data["%s"]', [TStockTakeItemAppearanceNames.Detail2])));   // Expression to access value from TListViewItem
  FMultiDetail3.DataMembers :=
    TObjectAppearance.TDataMembers.Create(
      TObjectAppearance.TDataMember.Create(
        cMultiDetail3Member, // Displayed by LiveBindings
        Format('Data["%s"]', [TStockTakeItemAppearanceNames.Detail3])));   // Expression to access value from TListViewItem
  FMultiDetail4.DataMembers :=
    TObjectAppearance.TDataMembers.Create(
      TObjectAppearance.TDataMember.Create(
        cMultiDetail4Member, // Displayed by LiveBindings
        Format('Data["%s"]', [TStockTakeItemAppearanceNames.Detail4])));   // Expression to access value from TListViewItem
  FMultiDetail5.DataMembers :=
    TObjectAppearance.TDataMembers.Create(
      TObjectAppearance.TDataMember.Create(
        cMultiDetail5Member, // Displayed by LiveBindings
        Format('Data["%s"]', [TStockTakeItemAppearanceNames.Detail5])));   // Expression to access value from TListViewItem
  FMultiDetail6.DataMembers :=
    TObjectAppearance.TDataMembers.Create(
      TObjectAppearance.TDataMember.Create(
        cMultiDetail6Member, // Displayed by LiveBindings
        Format('Data["%s"]', [TStockTakeItemAppearanceNames.Detail6])));   // Expression to access value from TListViewItem

  GlyphButton.DefaultValues.VertAlign := TListItemAlign.Center;
  GlyphButton.RestoreDefaults;

  // Define the appearance objects
  AddObject(Text, True);
  AddObject(MultiDetail1, True);
  AddObject(MultiDetail2, True);
  AddObject(MultiDetail3, True);
  AddObject(MultiDetail4, True);
  AddObject(MultiDetail5, True);
  AddObject(MultiDetail6, True);
  AddObject(Accessory, True);
  AddObject(GlyphButton, IsItemEdit);  // GlyphButton is only visible when in edit mode
end;

constructor TStockTakeItemDeleteAppearance.Create;
begin
  inherited;
  GlyphButton.DefaultValues.ButtonType := cDefaultGlyph;
  GlyphButton.DefaultValues.Visible := True;
  GlyphButton.RestoreDefaults;
end;

constructor TStockTakeItemShowCheckAppearance.Create;
begin
  inherited;
  GlyphButton.DefaultValues.ButtonType := cDefaultGlyph;
  GlyphButton.DefaultValues.Visible := True;
  GlyphButton.RestoreDefaults;
end;

function  TStockTakeItemAppearance.DefaultHeight: Integer;
begin
  Result := cDefaultHeight;
end;

destructor  TStockTakeItemAppearance.Destroy;
begin
  FMultiDetail1.Free;
  FMultiDetail2.Free;
  FMultiDetail3.Free;
  FMultiDetail4.Free;
  FMultiDetail5.Free;
  FMultiDetail6.Free;
  inherited;
end;

procedure TStockTakeItemAppearance.SetMultiDetail1(
  const Value: TTextObjectAppearance);
begin
  FMultiDetail1.Assign(Value);
end;

procedure TStockTakeItemAppearance.SetMultiDetail2(
  const Value: TTextObjectAppearance);
begin
  FMultiDetail2.Assign(Value);
end;

procedure TStockTakeItemAppearance.SetMultiDetail3(
  const Value: TTextObjectAppearance);
begin
  FMultiDetail3.Assign(Value);
end;

procedure TStockTakeItemAppearance.SetMultiDetail4(
  const Value: TTextObjectAppearance);
begin
  FMultiDetail4.Assign(Value);
end;

procedure TStockTakeItemAppearance.SetMultiDetail5(
  const Value: TTextObjectAppearance);
begin
  FMultiDetail5.Assign(Value);
end;

procedure TStockTakeItemAppearance.SetMultiDetail6(
  const Value: TTextObjectAppearance);
begin
  FMultiDetail6.Assign(Value);
end;
procedure TStockTakeItemAppearance.SetObjectData(
  const AListViewItem: TListViewItem; const AIndex: string;
  const AValue: TValue; var AHandled: Boolean);
begin
  inherited;

end;

function TStockTakeItemAppearance.GetGroupClass: TPresetItemObjects.TGroupClass;
begin
  Result := TStockTakeItemAppearance;
end;

procedure TStockTakeItemAppearance.UpdateSizes;
var
  LOuterWidth: Single;
  LInternalWidth: Single;

begin
  BeginUpdate;
  try
    inherited;

    // Update the widths and positions of renderening objects within a TListViewItem
    LOuterWidth := Owner.Width - Owner.ItemSpaces.Left - Owner.ItemSpaces.Right;
    LInternalWidth := LOuterWidth - Text.ActualPlaceOffset.X - Accessory.ActualWidth;
    if Accessory.ActualWidth > 0 then
      LInternalWidth := LInternalWidth - cTextMarginAccessory;
    Text.InternalWidth := Max(1, LInternalWidth);
  finally
    EndUpdate;
  end;

end;

type
  TOption = TCustomListView.TRegisterAppearanceOption;
const
  sThisUnit = 'ListItemDetailobjects';     // Will be added to the uses list when appearance is used

initialization
  // MultiDetailItem group
  TCustomListView.RegisterAppearance(
    TStockTakeItemAppearance, TStockTakeItemAppearanceNames.ListItem,
    [TOption.Item], sThisUnit);
  TCustomListView.RegisterAppearance(
    TStockTakeItemDeleteAppearance, TStockTakeItemAppearanceNames.ListItemDelete,
    [TOption.ItemEdit], sThisUnit);
  TCustomListView.RegisterAppearance(
    TStockTakeItemShowCheckAppearance, TStockTakeItemAppearanceNames.ListItemCheck,
    [TOption.ItemEdit], sThisUnit);
finalization
  TCustomListView.UnregisterAppearances(
    TArray<TCustomListView.TItemAppearanceObjectsClass>.Create(
      TStockTakeItemAppearance, TStockTakeItemDeleteAppearance,
      TStockTakeItemShowCheckAppearance));

end.
0
Robert
7/11/2013 11:36:01 PM
On Thu, 11 Jul 2013 14:31:30 -0700, Markus Humm <markus.humm@freenet.de> wrote:

>So you're against it because it's a new concept?

it's not new "concept", there's nothing new under the moon. it's a new implementation (or rather lack of support for older time-proven
technique) which is preventing porting of existing apps to newer platform as is and forcing to redesign those apps for questionable benefits
and obvious problems. and who's going to sponsor that?

end users do not care about "concepts" and "designs", all they need is decently working apps. preferably faster than slower

>Maybe LiveBindings are once changed (in a compatible way with today's
>implementation) reducing those issues?

"if grandmother had balls..." :)

it's way too often decent (and even brilliant) ideas were ruined by poor borland/codegear/emb implementation so I wouldn't hold my breath

>Data aware controls is just not the way to go. Too inflexible.

sure those are far from ideal and there are few weak points in the entire "dataset-datasource-datalink-dataaware component" stack but I've
been using those succesfully for more than 15 years so you better elaborate what were _your_ problems

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/12/2013 7:35:19 AM
On Thu, 11 Jul 2013 14:29:51 -0700, Markus Humm <markus.humm@freenet.de> wrote:

>I just don't understand what you have against a more flexible concept

and I just don't understand why should I waste my precious time and bother my brains about redesigning perfectly working apps using that new
shining "concept"

and no, I'm not against greater flexibility, on the contrary I always welcome that and if it really fits your needs I'm fine with it and
won't vote for LB extermination :)

>Why to we need to recreate every standard control in a data control

you don't. it's a job for component's vendor. for example some of devex components can work in 3 (!) different modes, including bound (to
datasource/dataset) and provider mode (where one should supply a conduit between the control and the actual storage providing the data, ORM
for example)

some people here even think that every control should be created as data-aware one from its very beginning and that really should be the new
"standard" for controls. instead of introducing newer problems and bugs they better polish and enhance existing (and working) approach

oh wait, that isn't very attractive for their marketing dept...

>fashion again? What's the added value in that? It will only lead to more

the added value is that many could keep using existing skills and expertise to produce what they need instead of investing (wasting?) their
resources

>bugs due to more code.

well, perhaps some vendors/developers should really stop producing any code at all minimizing the chances of new bugs and the entropy of the
universe :)

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/12/2013 7:35:54 AM
> {quote:title=Markus Humm wrote:}{quote}
> Am 10.07.2013 06:44, schrieb Steve Faleiro:
> > Robert Gilland wrote:
> > 
> >> I have programmed in Delphi since 1995 Delphi1
> >>
> >> I am now evaluating Delphi XE4.
> >>
> >> It boggles my mind, why embarcadero has lost the most important
> >> aspects of Delphi.
> >>
> >> Simplicity and Fast User Interface creation.
> >>
> >> I can easily see how Firemonkey can be improved to bring it in line
> >> with traditional Delphi Techniques by doing the following.
> >>
> >>
> >> 1. All Firemonkey controls need a data aware counterpart.
> >> 2. Firemonkey Styles need to be converted to TControl descendants.
> >> 3. ie. TLayout goes to TPanel ( TFMXPanel )
> >> 4. ie. TRectangle does to TFrame  TFMXFrame )
> >> 5. LiveBindings gets placed underneath ( TFMXDataSource )
> >> 6. Style Editor becomes a simple FMX Editor.
> >>
> >> Unless this is done, I cannot see how XE4 can really take off as a
> >> product
> >>
> >> Kind Regards,
> >>
> >> Robert.
> > 
> > Same feelings here. The quality of Firemonkey has not been good since
> > the first release. No joy. EMBT need to act on this as a top priority!
> > 
> 
> They know this. Issue is, that they also know they need to cover
> additional plattforms.
> 
> And I do not think all controls need a data aware counterpart. That's
> what LiveBindings are fore! (even if their implementation might not be
> what many of us want technology wise, but that's something different).
> LiveBindings are more flexible.
> 
> And why do all styles need to be converted to TControl descendants? WHat
> value does this bring to me? There are a few issues I guess, but I'm not
> sure that's an important one. Better spend the time for further bug fixing.
> 
> Greetings
> 
> Markus

LB depends RTTI. RTTI information in the bin(.exe) will greatly reduce the security.
Some programs do not need such detail RTTI information. The information not only used by programs itself but also helpful for crackers.

It is so strange that we must need LB do our job.
0
Wenjie
7/12/2013 10:51:04 AM
Vladimir Ulchenko wrote:

> On Thu, 11 Jul 2013 14:29:51 -0700, Markus Humm
> <markus.humm@freenet.de> wrote:
> 
> > I just don't understand what you have against a more flexible
> > concept
> 
> and I just don't understand why should I waste my precious time and
> bother my brains about redesigning perfectly working apps using that
> new shining "concept"

No one says you should.

But if you want to write code for other platforms than Windows, you
can't use the VCL, so then you'll have to use LiveBindings and FMX to
achieve the same.

-- 
Rudy Velthuis (TeamB)    http://www.teamb.com

Dow's Law: In a hierarchical organization, the higher the level, 
the greater the confusion.
0
Rudy
7/12/2013 12:54:48 PM
On Fri, 12 Jul 2013 05:54:48 -0700, Rudy Velthuis (TeamB) <newsgroups@rvelthuis.de> wrote:

>But if you want to write code for other platforms than Windows, you
>can't use the VCL, so then you'll have to use LiveBindings and FMX to
>achieve the same.

thank you capt. Obvious

btw there's nothing Windows specific behind dataset-stack in VCL so there are no technical reasons why the same couldn't be used for other
platforms

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/22/2013 6:45:03 AM
Vladimir Ulchenko wrote:

> btw there's nothing Windows specific behind dataset-stack in VCL so there are no technical reasons why the same
> couldn't be used for other platforms

You are correct; there are no technical reasons, however Rudy didn't say there were. OTOH, it is additional work to
create traditional data-aware controls for Firemonkey. If a third-party developer creates a Firemonkey control, they
don't even need to create a data-aware equivalent.

-- 
Dave Nottage [TeamB]
0
Dave
7/22/2013 7:07:24 AM
On Mon, 22 Jul 2013 00:07:24 -0700, Dave Nottage <"Dave Nottage (TeamB)" <>> wrote:

>OTOH, it is additional work to
>create traditional data-aware controls for Firemonkey

there is either additional work for component/platform vendor to make new platform as compatible with the older technologies as possible,
attract more delphi users by simplifying migration process and sell more copies or additional troubles for aforementioned delphi users to
redesign their apps from scratch. I believe it is the key point of this thread

>If a third-party developer creates a Firemonkey control, they
>don't even need to create a data-aware equivalent

OTOH if If a third-party developer creates a data-aware (or dual) FM control from the very beginning, end users won't even need to bother
with all that LB mess

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/22/2013 7:35:06 AM
> {quote:title=Dave Nottage wrote:}{quote}
> Vladimir Ulchenko wrote:
> 
> > btw there's nothing Windows specific behind dataset-stack in VCL so there are no technical reasons why the same
> > couldn't be used for other platforms
> 
> You are correct; there are no technical reasons, however Rudy didn't say there were. OTOH, it is additional work to
> create traditional data-aware controls for Firemonkey. If a third-party developer creates a Firemonkey control, they
> don't even need to create a data-aware equivalent.

But old TDBGrid is reliable.
I try periodically to find a reliable TDBGrid replacement for FMX so I can move my VCL projects. In this moment there is not.
I tried TGrid and TTMSFMXGrid and now both have the same issues when you move columns and try to edit. Someone from TMS said that this is because unresolved LiveBindings issues.
I'm just curious if someone has managed to use FMX for editing a table into a grid with basic things like moving columns.

Best Regards,
Cristian Peta
0
Cristian
7/22/2013 8:50:30 AM
On Mon, 22 Jul 2013 01:50:30 -0700, Cristian Peta <> wrote:

>But old TDBGrid is reliable.

but... but livebindings are so cute! </sarcasm>

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/22/2013 9:01:24 AM
> {quote:title=Vladimir Ulchenko wrote:}{quote}
> but... but livebindings are so cute! </sarcasm>

Maybe too cute to be reliable.
I understand why DevExpress do not have a grid or other components for FMX. DevExpress FMX components will be reliable or will not be at all.
It's sad but I still hope.

Best Regards,
Cristian Peta
0
Cristian
7/22/2013 9:18:31 AM
On Mon, 22 Jul 2013 02:18:31 -0700, Cristian Peta <> wrote:

>I understand why DevExpress do not have a grid or other components for FMX. DevExpress FMX components will be reliable or will not be at all.

let me quote Julian Bucknall (DevExpress CTO): "at this point in time, we do not see the market there that would repay major investments of
time, money and resources on our behalf. And as Darren rightfully says, it is not our job to convince people that FM is viable, it's
Embarcadero's"

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
7/22/2013 10:17:35 AM
Vladimir Ulchenko wrote:

>On Mon, 22 Jul 2013 02:18:31 -0700, Cristian Peta <> wrote:
>
>>I understand why DevExpress do not have a grid or other components
>>for FMX. DevExpress FMX components will be reliable or will not be
>>at all.
>
>let me quote Julian Bucknall (DevExpress CTO): "at this point in
>time, we do not see the market there that would repay major
>investments of time, money and resources on our behalf. And as Darren
>rightfully says, it is not our job to convince people that FM is
>viable, it's Embarcadero's"

Wise decision. If DevEx would have jumped on FMX it would have been a
major investment (and disapointment) for them, Embarcadero should first
make FMX a realiable solution for all platforms and stop making
breaking changes on each release, but once that is a fact and there are
still customers it could very well be a hit (at least that is what i
assume).

I'm very curious on the new FMX platform..
0
Marius
7/22/2013 6:03:20 PM
Reply:

Similar Artilces:

Is GNU Gettext for Delphi compatible with Delphi XE2 ?
The site http://dxgettext.po.dk declare support for Supports for Delphi 5-2009. Thanks in advance lior ilan wrote: > The site http://dxgettext.po.dk declare support for Supports for Delphi > 5-2009. > Thanks in advance It is, if you look in the forums mentioned in that website http://tech.groups.yahoo.com/group/dxgettext/ http://tech.groups.yahoo.com/group/dxgettext/message/3639 Regards Olivier ...

Delphi and Delphi for .Net
It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. I would like to know is it true all .Net application is slower than Win32 native applicaiton or it is Delphi for .Net only. Your information is great appreciated, Inung On 2011-06-21 18:20:17 +0100, Inung Huang said: > It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. > I would like to know is it true all .Net application is slower than > Win32 native applicaiton or it is Delphi for .Net only. If you are only running the code in the application once then, yes, yo...

League System compatible with Delphi 2010 or Delphi XE4
I am currently trying to write a league system using delphi to be used for an upcoming football tournamant I am running. However, I have encountered some difficulty in doing so. Does anyone have a league system they would give me the code for that is compatible with Delphi 2010 or Delphi XE4? ...

League System compatible with Delphi 2010 or Delphi XE4 #2
I am currently trying to write a league system using delphi to be used for an upcoming football tournamant I am running. However, I have encountered some difficulty in doing so. +Does anyone have a league system they would give me the code for that is compatible with Delphi 2010 or Delphi XE4?+ ...

vcljpg to vclimg, packages and Delphi 2006 vs Delphi 2010 compatibility
Hello, everybody. I have a package A which has vcljpg in its "requires" clause. I have another several packages B, C, D, E, etc which has A in theirs "requires" clauses. All packages are both Delphi 2006 and Delphi 2010 compatible. The problem is that there is no vcljpg package in Delphi 2010 and in order to compile the whole bunch of packages I have to change vcljpg to vclimg and compile. Unfortunately it renders the whole set of packages incompilable under Delphi 2006. Is there a way to create an alias for vclimg or vcljpg in order to get the same code...

SEPA components for Delphi with Source Code (Delphi 5
Hi all, in the european union change next year the Bankingformat to the SEPA Format. All peoples and companies must change the bankingssoftware and the costumer data form acountnummers in the new IBAN and BIC numbers. See: http://www.arma-it.de/shop/artikelueber.php?wgruppeid=211&wgruppe_offen=211 Functions: - generate SEPA XML'S - Calc IBAN - BIC Database (DE,AT and CH) Questions: vertrieb@arma-it.de PS: Bankinssoftware for Develpoers (Germany only) http://www.arma-it.de/shop/artikelueber.php?wgruppeid=212&wgruppe_offen=212 El 26/10/13 21:38, A...

Delphi 7 to Delphi XE2
Hi, Still using that old workhorse, Delphi7, but am going to the conference in London hosted by Embarcadero on Delphi XE2. Although I would like to "move with the times" and am keen to get the UNICODE and 64-bit support offered by the latest IDEs, I confess to being more than a little scared about all the UNICODE/String/AnsiString and 32/64 bit issues I'm probably going to fall over. Anyone recently upgraded from Delphi7 to one of the latest Delphi IDEs? Thanks, Alain On 03/02/2012 08:55, Alain Dekker wrote: > Still using that old workhorse, Delphi7, but...

Delphi XE / Delphi 2010
Hello! I noticed that Embarcadero® Delphi® 2010 Version is not on the list of products on Embarcadero page. Or is it still possible to buy it? Will RAD Studio XE compile programs written in Delphi 2010 without problems.? Thanks. Am 13.09.2010 09:04, schrieb Petra Nemec: > Will RAD Studio XE compile programs written in Delphi 2010 without problems.? As always you will probably have to recreate the projects as the import is still a bit -- special. Christian Hello! Does anybody know if it is still possible to get a Delphi2010 trial version (if yes where)? ...

from delphi 6 to delphi 2010
Hi. It is possible, with component RX, dxforumlibrary, InfoPower3000Pro, StringAlignGrid. Accepts communication BDE. Thank by comments. excequiel arostica wrote: >Hi. > It is possible, with component RX, dxforumlibrary, >InfoPower3000Pro, StringAlignGrid. Accepts communication BDE. > >Thank by comments. Rx is dead and sources are taken over by jcl/jvcl. I dont know about the rest of the components and i have no experiences with bde over the last 9 years. excequiel arostica wrote: > Hi. > It is possible, with component RX, dxforumlibrary,...

Delphi 7 to Delphi XE
Have been using Delphi 7 for many moons ( have got later versions but never upgraded to ) My first problem is: Component Palette. in XE it is a small toolbar docked in top right in Delphi 7 it gives a large view of all the components. I am struggling to be able to cope/access my components.in Delphi XE. Can I make the component pallette tool bar the same size as Delphi 7, or is there a fast way to view/choose all available components in XE, that I have not spotted yet? Kind Regards, Robert. Hi, What I know is that in Delphi 2010 and XE you can choose between t...

Delphi 4 to Delphi 2009
Hello, Thanks to all who answered my previous question. That was a great help. And atlast our client agreed to upgrade our delphi version from 4 to Delphi 2009. *Sigh*. But before that, I need to give the estimation and cost regarding the migration to delphi 2009. Can anyone tell me is there any tool to migrate from delphi 4 to delphi 2009 or just I need to compile our Delphi 4 application in Delphi 2009. I have read from the delphi 2009 feature matrix that Delphi 1 through Delphi 2007 import is possible in delphi 2009. But i am not that sure considering the size of our application. ...

Delphi for PHP or Delphi PRISM
Hi, I have the opportunity to develop a web-based library management system. Nothing fancy, just being able to do the usual CRUD stuff for books and provide a search facility. Borrowing is to be done via an email request to the library admin who then sends out the book(s). Since both Delphi for PHP and Delphi PRISM will enable me to develop the app, which one will allow me to deliver it in less time and also increase (even how small) my marketability as a web developer? Thanks. Phillip Flores Phillip Flores wrote: > Hi, > > I have the opportunity to develop a...

Delphi 5 to Delphi 6 and up
Dear List, Trying to add 7Zip compression support to my delphi application. I am using the ported 7Zip sdk (see their website, they have a link). I am stumped on how to rewrite a single function: function ReverseDecode(var Models: array of SmallInt; ....): ..... where the input is mostly a fixed size array of SmallInt. This code perfectly compiles and functions in Delphi 6 and up, but in Delphi 5 I get the error: There is no overloaded version of 'ReverseDecode' that can be called with these arguments And obviously, the input (fixed) isn't the same as the param de...

Delphi 5 To Delphi 2009
I upgraded to Delphi 2009 from D5. The install says I can install Delphi and/or C++. Delphi installed OK but I see nothing of C++. What am I missing or does my upgrade not include C++? Thanks It depends on what you bought. If you bought Delphi 2009 only, that's what you get. If you bought Delphi 2009 and C++ Builder 2009 you get both. My guess is you got Delphi 2009 only. The simplest way to verify is look your invoice - it should say I would think. You could also go to members.embarcadero.com, login, then click on my registered products. There will be a textual description of...

Web resources about - Making Firemonkey more compatible with Delphi - embarcadero.delphi.non-tech

Firemonkeys - GamesIndustry International
The world's leading games industry website. Get insight from todays industry leaders with news, interviews and analysis of global gaming trends. ...

Firemonkey’s Real Racing 3 To Launch At The End Of February
In September, Apple demoed Firemonkey’s Real Racing 3 at the iPhone 5 event . Three months later and the game has yet to show up in the App Store. ...

EA Games and Firemonkey Bringing Real Racing 3 to Android, Fasten your Seat Belts
Start up your engines race fans, EA Games is teaming up with Firemonkey to bring Real Racing 3 to mobile devices. If you’re a fan of more realistic ...

EA's Firemint and IronMonkey Studios Merge to Become FireMonkeys
... game development studios into one mega-studio in Australia. Firemint and IronMonkeys will be merged into a single studio now known as Firemonkeys ...

News: Firemonkeys announces Real Racing 3
Firemonkeys, a new gaming subsidiary of Electronic Arts born from the merger of FireMint and IronMonkey, has announced the coming release of ...

firemonkeys - iMore
EA has pushed out another impressive update to its equally impressive iOS racer, Real Racing 3, that for the first time brings cars from Ferrari ...

Firemonkeys on Real Racing 3 going free-to-play
... got a hands-on preview of Real Racing 3. We also spoke with Ptolemy Oberin, one of the game’s programmers and project lead at developer Firemonkeys, ...

Real Racing 3 coming in 2012 from Firemonkeys
The first game from recently merged developer Firemonkeys is Real Racing 3 , the developer revealed moments ago during EA's Summer Showcase event ...

Firemonkeys Previews Real Racing 3 for iPhone and iPad
Firemonkeys, the new combined studio from EA combining the IronMonkey and Firemint gaming studios, has announced the development of Real Racing ...

EA Mobile Moves: IronMonkey & Firemint Merge Into “Firemonkeys,” Now Have 50M Players Between
... that it is merging two top mobile game studios, IronMonkey and Firemint , which will fittingly combine to create a new company, called Firemonkeys. ...

Resources last updated: 1/3/2016 2:48:28 PM