Is there simpler way of saying that Delphi component/control is supported on all platforms?

Asked 15/12, 2014 at 15:4 Answered 17/9 at 23:56

In order to make Delphi component/control available for all (currently) available platforms I have to write

  [ComponentPlatforms(pidWin32 or pidWin64 or pidOSX32 or pidiOSSimulator or pidiOSDevice or pidAndroid)]

before component/control declaration:

type
  [ComponentPlatforms(pidWin32 or ...)]
  TMyComponent = class(TComponent)
  end;

Is there a shorter way of writing that component supports all current and future platforms?

Landan answered 15/12, 2014 at 15:4 Comment(14)

Off the top of my head: const pidAll = pidWin32 or pidWin64 or pidOSX32 or pidiOSSimulator or pidiOSDevice or pidAndroid; then [ComponentPlatformsAttribute(pidAll)]. – Vi 15/12, 2014 at 15:18

@500-InternalServerError I already thought of that but it is a bit clumsy when you have to make that definition available to hundreds of units that don't necessarily have common unit in uses clause. – Landan 15/12, 2014 at 15:25

@DalijaPrasnikar That's your problem. – Pinhole 15/12, 2014 at 15:36

@500-InternalServerError Your comment inspired me to try with 0 and it works. Thanks. – Landan 15/12, 2014 at 15:37

I filed following report for introducing pidAllPlatforms quality.embarcadero.com/browse/RSP-9839 – Landan 15/12, 2014 at 17:45

Now I cannot reproduce what I reported in my answer. I'm very confused. – Pinhole 15/12, 2014 at 19:50

@David I can consistently reproduce described behavior in XE2, XE3, XE4 – Landan 15/12, 2014 at 19:51

I definitely observed the behaviour that I reported, but now I cannot reproduce. Anyway I have stepped back! Sorry for the confusion. – Pinhole 15/12, 2014 at 19:56

@David No problem, at least now I know I am not imagining things... – Landan 15/12, 2014 at 19:58

I'm impressed. You're able to definitively state that you know for certain that your component will work with all future platforms. I wish I had that level of clairvoyance... Yes, I'm joking; but my point remains the same. If you follow the adage that "until it's tested otherwise, the code is broken and non-functional", this is a very dangerous position to take. – Annunciata 15/12, 2014 at 20:7

@AllenBauer If by any chance my components will fail to function on future platforms I will certainly make corrections, but those components have same chance to function correctly as TComponent itself has because they do not contain any platform specific code nor 8-bit strings. – Landan 15/12, 2014 at 20:14

@AllenBauer Can you please shed some light on what is expected behavior for TComponent descendants that do not have ComponentPlatformsAttribute specified? In XE2, XE3 and XE4 I can only see such components for Win32. – Landan 15/12, 2014 at 20:20

@AllenBauer If the component derives from TComponent, and uses nothing more complex than the functionality made available by the language and the basic units of the System namespace, surely it would be reasonable to mark the component as being agnostic of platform. – Pinhole 15/12, 2014 at 20:36

Who defines complexity? Where do you draw the line? You can certainly look at specific instances and make some assumptions, but they're just that; assumptions. If adding a new attribute for a new platform is considered onerous where the testing effort would be far more important and necessary... then I can't really help here. If it's helpful in your specific instance to define your own constant that encompasses all platforms and you used it throughout your own code... nothing is stopping you from doing just that. – Annunciata 15/12, 2014 at 21:55

There is no simpler way, but you could define those as one constant:

const
  AllCurrentPlatforms = 
    pidWin32 or pidWin64 or pidOSX32 or 
    pidiOSSimulator or pidiOSDevice or pidAndroid;

and use that each time you create a new component. But, assuming you don't produce that many components, what is wrong with writing it out in full, the few times it is needed?

I also assume that if you simply omit the attribute, the component will be considered as supporting all platforms. You could test that.

There is actually a similar constant AllPlatforms in ToolsAPI/PlatformAPI but that unit is not for general runtime use.

Ragin answered 15/12, 2014 at 16:6 Comment(7)

Could Current be rephrased into something that actually tells what timeframe current refers to? E.g. All2014Platforms or AllXE7Platforms? – Olivia 15/12, 2014 at 17:16

Omitting ComponentPlatformsAttribute makes component available only on Win32 platform (XE2-XE4) – Landan 15/12, 2014 at 17:28

Why a clumsy solution? It is the standard solution if you must combine several constants. And omitting the ComponentPlatformsAttribute does, AFAIK, tells the system that the component is not tied to certain platforms. Take a look at components that do not have this attribute. – Ragin 15/12, 2014 at 18:6

@NGLN: You can name it however you want. – Ragin 15/12, 2014 at 18:7

Note that anything in or under ToolsAPI is not meant for runtime use. – Ragin 15/12, 2014 at 18:10

I have accepted this answer as correct because it is proper way to do what I asked for. However, I have to note that I am not going to use this solution myself and will go with my more hackish and shorter way, acknowledging all possible issues that approach might bring. – Landan 16/12, 2014 at 18:50

@Olivia I like that suggestion as it clearly marks for which state in time the assumption was made. – Kandi 27/12, 2014 at 9:49

Simpler, absolutely hacky, way of making component/control available for all platforms:

  [ComponentPlatforms(0)]

or in another way

  [ComponentPlatforms($FFFF)]

Landan answered 15/12, 2014 at 15:36 Comment(4)

Hard to see why 0 would work. That's an empty bitset. Of course, the complete lack of documentation leaves us guessing. $FFFF has every bitset, but is quite different from pidWin32 or pidWin64 or pidOSX32 or pidiOSSimulator or pidiOSDevice or pidAndroid. You've just declared support for all future platforms. I'm not very keen on this approach at all. – Pinhole 15/12, 2014 at 15:46

A common unit with some predefined const is the best way. At the moment you have to touch every unit, so simply add the unit and use the const from there. You will love that in the future when you have to add more platforms. const pidDesktop = pidWin32 or pidWin64 or pidOSX32 {or pidOSX64 or pidLinux}; – Prone 15/12, 2014 at 16:2

@David since those components are platform agnostic and will be supported on every future platform there is no problem. – Landan 15/12, 2014 at 16:59

But that is different from what you have written in the question isn't it? – Pinhole 15/12, 2014 at 17:6

In RAD Studio 10.3 Rio Update 2 and later, there is a pidAllPlatforms constant defined in the System.Classes unit:

[ComponentPlatforms(pidAllPlatforms)]

Idealize answered 17/9 at 23:56 Comment(0)

Recommended topics

Hot tags