You can absoultely hit both CS4 & CS5, Mac & PC -- we do! Hell, we used to hit CS3, CS4 and CS5
Your problem with CS5 & CS4 is probably that you're using a suite version that is only available in CS5. When Adobe updates a suite, they still make the old version available, but the headers will always use the version that shipped with their Illustrator by default (makes sense). So, for example, the Art Suite might be version 14 in CS4 and 15 in CS5. If you use the CS5 headers, kArtSuiteVersion is 15, but 15 doesn't exist in CS4.
Its easy to see if that's the problem -- add a message if AcquireSuite fails and have it print out the suite & version that failed. If that's the case, you'll just need to look at the CS4 SDK and figure out what version it shipped with (likely one less than you requested!). If you're not using anything added in the CS5 version, just switch the types & version requested to the CS4 one and after a recompile, you should be fine. Of course, this may repeat for several suites It might be faster to look at what suites you're requesting and then just check each one. A fast way is to look in the legacy folder -- if theres an AI140*.h version of your suite, that means it was updated in CS5, and you'll run into this problem.
As for the ADM, well, we had the same experience. That's why we switched to Qt. There are undoubtedly other cross-platform toolkits you could use, but that one will work (albeit with some work). The next version of Illustrator won't even have the ADM in it, so its definitely wise to avoid the ADM at this point.
I'm not too familliar with Flex, but I believe you can hit CS4 & CS5 with the same UI. I'm not the one to answer that unfortunately, as we don't use Flex. There's another thread from the last week that discussed the finer points of 3rd party vs Flash UI that you might find useful. It should be one or two down from this one in the thread list.
Ok so I think a suite conflict is my issue. I built the new plugin template from the CS4 SDK in Xcode and it runs in CS4 and CS5 fine on my machine (I get the hello and goodbye message popups). It still concerns me that the sample code for LiveDropShadow project from the CS4 SDK sample code built fine but doesn't open in CS4.
I'll have to find the place where it acquires the Plugin Group suite and check the version.
Along those same lines, do you recommend developing from the CS4 SDK and then tweaking it for CS5 if needed or developing from the CS5 SDK and using the previous suite versions when necessary?
It depends on whether you need CS5 functionality. As soon as you want to call something only found in the CS5 SDK, you're kind of stuck going with the CS5 headers -- I strongly recommend you do not mix the headers from the two SDKs. If you don't even call anything CS5-specific though, CS4 headers are just fine (though I'd still test it in CS5!).
As A. Patterson said, in most cases you can just use the older SDK. Since Adobe won't continue to support the older SDK, testing is a must. But we haven't run into any real issues using the older version. We didn't need any specific feature sets in CS4 and CS5 specific to those SDKs... so we are currently supporting a plugin for CS3/4/5 built on the CS3 SDK.
Mr. Patterson... I am back to trying to get my plugin to work on both Windows and Mac.
I wrote the initial code in VS 2008 for Windows and it worked but not on a Mac. I switched to XCode IDE and it took some configuring, but I got it to work for multiple processors and different versions of Illustrator. Now I need to get the code that I wrote for the mac to work on 2 PCs.
So do you have one code base that works for both? Do you have to compile for the different platforms? Do you have to create the resource specific files?(.r files for mac, .rc for windows).
Thanks in advance,
We use one code base for both platforms. We do have #ifdefs in the odd place but mostly that's not Illustrator code; that's usually for UI (and for low-level hacks). You'll need to have two different resource files, at least for anything that goes into an OS resource file. We use Qt for 95% of our UI though, and that's cross-platform so Mac & Windows share all that (except for the odd snippet in #ifdef).
I'm not sure what you mean by 'compile for the different platforms'. If you Mac & Windows, yes, you need to build different binaries for both -- there's nothing that runs on both platforms. If you mean different versions of Illustrator, we currently create one binary for a sequence of Illustrator versions per OS platform. So on Windows we have a binary that runs in CS4 & CS5. We have a similar binary for the Mac. Not too long ago, we had one that supported CS3, CS4 & CS5, but dropped CS3 support recently. It's worth noting that apparently we're odd in this regard; from discussion with other Ilustrator developers it seems that most opt to have Illustrator version-specific binaries. It's also worth noting that as things currently stand, that will be required of everyone going forward with the next version of Illustrator (this may change, but it appears that in the next version of the Illustrator they will no longer provide access to older suite versions). So if you can get a binary that works in CS4 & CS5 now, it definitely won't be possible to do one that also supports the next version of Illustrator -- it will require its own binary. As will whatever version comes after that.
To be more specific, do you build both platform specific binaries from the same IDE? I used Visual Studio to generate the windows binary and worked fine. I used XCode to generate the Mac binary, worked fine. I can't figure out a way to generate both from one IDE. And I am going to have to generate a lot of the compiler directives because I have ODBC code in there as well and it is different code cross platform.
I am not aware of any way you could create both binaries from one IDE. I am not even aware of a way to build both binaries on the same platform (meaning you will need to build the mac binaries from a Mac OS and a windows binary from a Windows OS).
My team is using the same approach as A. Patterson. We have one source code base, but separate project files for visual studio and xcode (with IFDEFs only as needed). We also are creating one binary for each platform that supports all of our currently supported CS versions. (i.e. we are building a product that supports CS4 & CS5/5.5 by building upon the CS4 SDK). We have not had any compaitibility issues so far (and have not yet needed any CS5 specific functionality).
Ok. So I can compile the single code base with a few compiler directives (#ifdef MAC_ENV ... or #ifdef WIN_DEV) and two resource files (.rc for windows and .r for mac) in the respective IDEs. I also needed to tell both IDEs where all the additional include files were located - this is a huge pain in the ... but at least it only has to be done once.
I have actually opened the plugin in multiple AI versions (single binary for the platform) on both platforms. (Does a happy dance ... thanks everybody for all your help).
Unfortunately now I have to figure out how to translate mac resource positioning to windows positioning so everything looks relatively the same. Any known documentation out there or am I just going to have to play with the positions?
There's no translation between the two. Yeah, it sucks, we just have to eye-ball it. Frankly, even if you could translate the coordinates & such between the two, they use different fonts & such so that wouldn't be much help.
This is just another reason we do as much UI as possible in Qt as opposed to the ADM
I am starting to convert my plug-in in Windows CS4 and CS5 to Mac.
Which version of Xcode should I be using, will the latest XCode work?
And do I have to use something like Qt for Mac or can I use native AI GUI in CS4 and CS5?
Maybe I should start with Qt, because eventually I have to support CS6 and above?
i use hotdoorcore now.
but i find it not support chinese character？
We use Hot Door CORE to create CADtools which supports Chinese and Japanese characters, so I know it works. Please give a more detailed question, including sample code, on the Hot Door CORE forum and we will do our best to help.
Hot Door, Inc.