2

My aim is to build a Flex library that is compatible with clients (both other libraries and Flex applications) build on Flex versions ranging from 3.5B to 4.6. Also, I'd like to be able to use functionality from as recent a version of Flex as possible in my library, although this is a secondary concern compared to compatibility.

Is it necessary that I use a Flex version no greater than 3.5B?

A particular difficulty I'm running into with 3.5B is when I statically link Flex into my library and use it in a Flex 4.5.1A project, it fails with a smörgåsbord of compile time errors like 1044: Interface method get baseline in namespace mx.core:ILayoutElement not implemented by class panels:BasePanel.

Runtime shared linking appears to somewhat address the issue. When I compile the library for Flex 3.5B with RSL of Flex set, it produces a swc that compiles cleanly in my 4.5.1A project and basically works, but I'm uncomfortable with the fact that the static option doesn't work. I feel that runtime linking in this way seems odd since a project built with Flex 3 is runtime linked with Flex 4 (any why doesn't the runtime linking produce the same interface complaints?).

Runtime linking appears so squishy (namely, I can even build my original project with 4.6 and just be super careful not to use pre-4.6 functionality and use it in a 3.5 project), that I'm uncomfortable with it with my current level of understanding.

Steven
  • 17,796
  • 13
  • 66
  • 118

1 Answers1

3

Is it necessary that I use a Flex version no greater than 3.5B?

A lot of things change in Flex Framework classes between versions. So, the only way to guarantee that a SWC will work for multiple versions of the Flex SDK is to have no dependencies into the Flex SDK.

Creating a SWC library with Flex dependencies in Flex 3.5B will not necessarily work in Flex 4, or Flex 4.5 or Flex 4.6.

I've had a lot of trouble with our commercial components. Take the AutoCompleteComboBox, as one example. We currently have 5 different versions of it (Flex 3, Flex 3.2, Flex 3.5, Flex 4, and Flex 4.5 ). Each version has bug fixes specific to that version of the SDK. Flex 3.5 was a full re-write of the component because of significant changes to the Flex ComboBox, which our component extends.

Additionally, if you use a library which is compiled on a different version of the Flex SDK than your current version, sometimes the Flex compiler will give "odd" compile errors that are solved by recompiling your library with the same SDK version as your main app. I think that is exactly what you're seeing.

So, the answer is that, if you want to use a SWC with projects created for multiple versions of the Flex SDK, the only way to guarantee compatibility is to have no dependencies to the Flex SDK in your SWC.

JeffryHouser
  • 39,401
  • 4
  • 38
  • 59
  • Thanks for the detailed answer and examples. I took a look at your AutoCompleteComboBox, and it's cool stuff (weird how 4.swc is a radically different size than 35.swc or 45.swc; did that file statically link in Flex or something?). My Flex library doesn't actually use any Flex components and afaik uses the framework only to package the swc, so I wonder if I might not be able to get away with building it with 3.5B and use it across all Flex client app versions. It'd be more tenuous than actually making one swc per Flex version, but it might make for a simpler interface... – Steven Jun 13 '12 at 21:37
  • I'm not sure whyt he 4.swc is so much larger than the 35 SWC or 45 SWC. I can only guess that the 4.SWC has the framework compiled in while 35 and 45 are using RSLs; but I'd have to dig deeper into our actual setup. I believe you'll have no problem sharing your SWC across different SDKs if it is a Flexless library. However, the compiler errors you're seeing may mean you're stuck creating different versions. – JeffryHouser Jun 13 '12 at 22:36