CompuServe Messages

>> replacement available (gee, you guys could at LEAST have given us some sort of OLE Automation capabilities that we could call from Visual BASIC or Borland Delphi or some such!). << implementing a programmable interface (read creating an interpretive compile) is not such an easy task…. and creating an SDK or an API that isn't shameful and offers adequate access to the program's internal functions is also no easy matter. VB was on the list of things to get in first release, along with hundreds of other requests. the programmers and product managers are aware of the open ended architecture needed in the program, but only so much can be done in the first release before it has to become profitable. >> POCO does have some "holes" in it, though, and it looks like they will never be filled due to the emphasis shift to AAS. It's just another example of programmers leaving easily-implemented features out of something just because THEY couldn't think of a reason any of us would want it. << i don't know about that… (meaning i disgree as to the reason)… and no one has said that Animator Pro will definitely not be updated. also, programmers aren't usually the ones who make these types of decisions. at all. >> Frame. POCO implements the Copy and Exchange functions but NOT the Paste function. This meant my FIELDER.POC (in the Library here) is WAY slower than << there are a lot of areas that POCO does not address in the program… mask creation, access to separation tools (we wound up having to write our own), some weirdness with the LoadCel and SaveCel functions… what language doesn't have its glitches. i use POCO every day. it is invaluable, so i know what you're saying here. i just question your reality of "why things happen." from experience, i know why this type of interface was left out and it wasn't because of programmers. 🙂 -dave