Re: XCMD Limitations
Thanks to Richard and Brian (and Jim off-list) for replying. In the meantime Kevin Miller confirmed that the supported list of callbacks is defined as the 1.2 spec, and the magic of google (after I'd searched a huge box with 10 years of Apple Developer CDs - apparently I didn't keep them going back far enough!) located an old copy of the glue. I've now implemented some headers to switch out the newer calls, recoded the ones that were needed, the external is working fine. But I'm still confused as to which of the HC callbacks are supported. The 1.2 spec that I found lists 27. Of these, only 11 are in the MetaCard XCmdGlue.h - but I know that my external is using at least some of the others, eg ZeroToPas. Perhaps Scott wishes to deprecate the others in externals written specifically for MC/Rev - fair enough. But that still leaves anyone with an existing external to modify (possibly to make cross-compatible with MC and HC) somewhat in the dark. So I still think it would be nice to a) get a definitive list of the HC compatible callbacks that are supported, in addition to the MC-specific ones b) if the engine handled an unsupported callback more gracefully. Just as background, since a number of people suggested this shouldn't be necessary. The situation is that we've got a project doing an upgrade to a system we created some years ago. One part that needs modification is a HyperCard stack that does a huge data munge every month or so, taking some 4-6 hours in total. I proposed moving this stack into MC (actually Rev) first, and the upgrade on that version; on the basis of speed, better ongoing support, etc. The problem is that there is of course a limited budget and some outcomes in terms of new functionaliy that have to be achieved; and the transition obviously has risk factors. I therefore negotiated a strictly capped budget to attempt the transition; if I can't prove that all problems have been solved by the time I've spent that, we're just going to stick to making changes to the existing system. Unfortunately because of the lack of information (= my lack of knowledge) about exactly what should work in the XFCN, and the fact that when an unsupported call was made the entire machine froze, so that the process of investigation was incredibly drawn out, I've blown a lot of the budget just getting past this particular hurdle. thanks again to all who helped, Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XCMD Limitations
Thus far I've managed to avoid writing a single external since I started working with MC in '97 (I hired out the only one I couldn't make in native MetaTalk), so my knowledge of how MC works with externals is very limited. Hopefully somone with experience with this can take a moment to fill in the details... -- Richard Gaskin Yes, It is nice not to have to use externals, isn't it :-) I had to use them in Hypercard. So far, I've been able to work within Metacard happily without them. And it makes for easier cross-platform development (though I still haven't made the official leap to release a Windoze program). My current project will be the first... Shari -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XCMD Limitations
On Fri, 25 Oct 2002 [EMAIL PROTECTED] wrote: In the meantime Kevin Miller confirmed that the supported list of callbacks is defined as the 1.2 spec, and the magic of google (after I'd searched a huge box with 10 years of Apple Developer CDs - apparently I didn't keep them going back far enough!) located an old copy of the glue. I've now implemented some headers to switch out the newer calls, recoded the ones that were needed, the external is working fine. But I'm still confused as to which of the HC callbacks are supported. The 1.2 spec that I found lists 27. Of these, only 11 are in the MetaCard XCmdGlue.h - but I know that my external is using at least some of the others, eg ZeroToPas. Right: we didn't put the rest in the MC external API because they're either standard C library routines, or are only needed by routines written in Pascal (which the MC external API doesn't support). Perhaps Scott wishes to deprecate the others in externals written specifically for MC/Rev - fair enough. But that still leaves anyone with an existing external to modify (possibly to make cross-compatible with MC and HC) somewhat in the dark. So I still think it would be nice to a) get a definitive list of the HC compatible callbacks that are supported, in addition to the MC-specific ones As I've stated before, this is the HC 1.2 API, and includes the conversion routines for Pascal strings and such. Don't know where you'd find this list now, given that it's circa 1989 (we have the original 1.2 HC doc that has it), but here's the list directly out of the engine source: xreqSendCardMessage xreqEvalExpr xreqStringLength xreqStringMatch xreqSendHCMessage xreqZeroBytes xreqPasToZero xreqZeroToPas xreqStrToLong xreqStrToNum: xreqStrToBool xreqStrToExt xreqLongToStr xreqNumToStr xreqNumToHex xreqBoolToStr xreqExtToStr xreqGetGlobal xreqSetGlobal xreqGetFieldByName xreqGetFieldByNum xreqGetFieldByID xreqSetFieldByName xreqSetFieldByNum xreqSetFieldByID xreqStringEqual xreqReturnToPas xreqScanToReturn xreqScanToZero You can also find this list in the file HyperXCmd.h if you can find that file for HC 1.2 or earlier. I can only find 2.X versions which have lots of other stuff that we can't support because it's specific to the architecture of HyperCard (e.g., external windows, TextEdit handles, their debugger, etc.) b) if the engine handled an unsupported callback more gracefully. It does what the API spec specifies, which is to return xresNotImp for unsupported functions. Of course you probably won't find too many externals that handle this correctly given that so few of them were ever tested with anything other than HC. Just as background, since a number of people suggested this shouldn't be necessary. The situation is that we've got a project doing an upgrade to a system we created some years ago. One part that needs modification is a HyperCard stack that does a huge data munge every month or so, taking some 4-6 hours in total. I proposed moving this stack into MC (actually Rev) first, and the upgrade on that version; on the basis of speed, better ongoing support, etc. The problem is that there is of course a limited budget and some outcomes in terms of new functionaliy that have to be achieved; and the transition obviously has risk factors. I therefore negotiated a strictly capped budget to attempt the transition; if I can't prove that all problems have been solved by the time I've spent that, we're just going to stick to making changes to the existing system. Unfortunately because of the lack of information (= my lack of knowledge) about exactly what should work in the XFCN, and the fact that when an unsupported call was made the entire machine froze, so that the process of investigation was incredibly drawn out, I've blown a lot of the budget just getting past this particular hurdle. Debugging externals is a nightmare in the best of cases. Debugging where you're intimate with the details of neither the host nor the external borders on hopeless. About the only recommendation I have for working through this is to do your development on OS X where at least you can answer your email while you're waiting for your classic box to reboot ;-) Regards, Scott thanks again to all who helped, Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XCMD Limitations
on 25/10/02 5:56 pm, Scott Raney wrote here's the list directly out of the engine source: xreqSendCardMessage xreqEvalExpr xreqStringLength xreqStringMatch xreqSendHCMessage xreqZeroBytes xreqPasToZero xreqZeroToPas xreqStrToLong xreqStrToNum: xreqStrToBool xreqStrToExt xreqLongToStr xreqNumToStr xreqNumToHex xreqBoolToStr xreqExtToStr xreqGetGlobal xreqSetGlobal xreqGetFieldByName xreqGetFieldByNum xreqGetFieldByID xreqSetFieldByName xreqSetFieldByNum xreqSetFieldByID xreqStringEqual xreqReturnToPas xreqScanToReturn xreqScanToZero You can also find this list in the file HyperXCmd.h if you can find that file for HC 1.2 or earlier. Thanks - diligent Googling eventually turned it an old version of HyperXCmd.h, but it's even better to have the list direct from the source's mouth (so to speak) b) if the engine handled an unsupported callback more gracefully. It does what the API spec specifies, which is to return xresNotImp for unsupported functions. Of course you probably won't find too many externals that handle this correctly given that so few of them were ever tested with anything other than HC. Mea culpa - I confess I've never ever checked for this, in a decade of writing HC externals... Debugging externals is a nightmare in the best of cases. Debugging where you're intimate with the details of neither the host nor the external borders on hopeless. About the only recommendation I have for working through this is to do your development on OS X where at least you can answer your email while you're waiting for your classic box to reboot ;-) Thanks! At least in this case I was intimate with the external. And next time I'll know where to go looking. Cheers, Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 PS - apologies to the list if a mail my mouse finger slipped on, which simply repeats the whole of Scott's message, gets through the moderator. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XCMD Limitations
on 23/10/02 11:46 pm, Richard Gaskin wrote Perhaps it could be rewritten in native MetaTalk I wasn't clear enough, sorry. The stack uses about 25 XFCN/XCMDs. I'm sure that I can recode all of them in native MetaTalk except this one. This one has to be in C. It uses proprietary libraries and custom code which has to be shared with some other apps to guarantee accuracy. Recoding in another language is not an option, even if time was not a factor. I've negotiated an allocation of a limited time to demonstrate that the system can succesfully be transitioned to MC/Rev; otherwise it's going to go elsewhere. I can recode the other externals in native MetaTalk, and if we get to continue down this path I will, for speed and cleanliness; but if I can't get the whole thing working quite quickly, that path will be capped. But in any case this function is core to the whole project, so I have to get it reliably working. I have the source code, so if I know what the problem areas are I expect I can code round them (it doesn't need to interact with the host in any very interesting ways). I've already fixed one crash by re-implementing StrToRect. The problem is I need to know the full set of unsupported calls - I can't afford to just fix the ones that I find which crash, and not know if there are some others that I just haven't come across in testing yet. Obviously Scott knows which callbacks he implemented. Is there a published list anywhere? TIA, Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XCMD Limitations
Obviously Scott knows which callbacks he implemented. Is there a published list anywhere? If you really want to be safe, I would suggest recompiling as a Metacard-native external. Or else eliminate all the callbacks- are there any that really need to be made and not done internally? You can find the MetaCard external package at ftp.metacard.com- you should only need to change the code in your main() routine to use the appropriate MetaCard callbacks. HTH, Brian
Re: XCMD Limitations
Ben Rubinstein wrote: I've negotiated an allocation of a limited time to demonstrate that the system can succesfully be transitioned to MC/Rev; otherwise it's going to go elsewhere. I can recode the other externals in native MetaTalk, and if we get to continue down this path I will, for speed and cleanliness; but if I can't get the whole thing working quite quickly, that path will be capped. If MC can't run a particular XCMD/XFCN, chances are no other program but HyperCard itself will be able to either. With an admittedly limited understanding of the project, it would seem that even in the the worst-case scenario -- if they need to recode the external -- they'd still save money using MC (assuming relying on HC isn't an option). What alternatives would be more cost-effective? Obviously Scott knows which callbacks he implemented. Is there a published list anywhere? Wouln't the list you need be present in the headers files (XCmdGlue.h, etc.) in the external example? Here's a partial list from XCmdGlue.h: extern void SendCardMessage(); extern void SendMCMessage(); extern char *EvalExpr(); extern char *GetGlobal(); extern void SetGlobal(); extern char *GetVariable(); extern void SetVariable(); extern void GetVariableEx(); extern void SetVariableEx(); extern void GetArray(); extern void SetArray(); extern char *GetFieldByName(); extern char *GetFieldByNum(); extern char *GetFieldById(); extern void SetFieldByName(); extern void SetFieldByNum(); extern void SetFieldById(); extern void ShowImageByName(); extern void ShowImageByNum(); extern void ShowImageById(); As a general rule, the HyperCard 1.x suite is widely supported by programs that support XCMDs, but any callbacks specific to the HyperCard 2.x suite are supported by none by HC itself. Thus far I've managed to avoid writing a single external since I started working with MC in '97 (I hired out the only one I couldn't make in native MetaTalk), so my knowledge of how MC works with externals is very limited. Hopefully somone with experience with this can take a moment to fill in the details... -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 2.0: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XCMD Limitations
I think there are pretty much two options here. One is to recode as a native MetaCard external- this is not hard to do, the only things that change are a) callbacks and b) parameter parsing and return values. If the XCMD is written clearly (i.e. one parameter parsing block of code and a generic routine for building the return value), this is usually trivial. I've managed to write code in the past that compiles as XCMD or Metacard-native based on a couple of #ifdef's. The only other options I see would be to carefully recode the callbacks. What callbacks exactly does it use? I find there is almost never a compelling reason to use any callbacks that you couldn't code yourself instead. The exception with Hypercard of course was their external windowing code. That you won't be able to replicate without wholesale changes to your approach. One suggestion if you decide to stay with the XCMD: try taking your copy of HyperXCmd.h and commenting out the prototypes for all of the callbacks. Now recompile and you should get an error for each one. From this you should be able to compile a list of the callbacks used. The simple ones are trivial to replace: StrToRect, StrToNum, etc. In fact, they'll run faster if you just call the appropriate C function instead. If you are really stuck, you'll probably need to post some actual code to get much better suggestions. If you'd like and you can, send me something off-list and I'll look it over. HTH, Brian Thus far I've managed to avoid writing a single external since I started working with MC in '97 (I hired out the only one I couldn't make in native MetaTalk), so my knowledge of how MC works with externals is very limited. Hopefully somone with experience with this can take a moment to fill in the details...
XCMD Limitations
Is there a reference anywhere to the limitations on XCMD/XFCNs? I've got a limited time budget to try to convert a big complicated stack to Rev; and I'm crashing in an XFCN. It's not an option to recode this XFCN; it uses custom libraries of proprietary code. It's going to be a big pain in the bottom to work through to find out where it's crashing (the entire machine locks up each time) so I could use some hints. I know that the callbacks to do with windows don't work. Are there others? Would it be correct to assume that MC implements all the HyperCard 1.0 callbacks, but none of those introduced in HC 2.0 (or whenever it was)? Is there a list somewhere of the supported or unsupported callbacks? Are there any other guidelines? Is there any handy debugging mode built into the engine to help? TIA, Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: XCMD Limitations
Ben Rubinstein wrote: Is there a reference anywhere to the limitations on XCMD/XFCNs? I've got a limited time budget to try to convert a big complicated stack to Rev; and I'm crashing in an XFCN. It's not an option to recode this XFCN; it uses custom libraries of proprietary code. It's going to be a big pain in the bottom to work through to find out where it's crashing (the entire machine locks up each time) so I could use some hints. I know that the callbacks to do with windows don't work. Are there others? Would it be correct to assume that MC implements all the HyperCard 1.0 callbacks, but none of those introduced in HC 2.0 (or whenever it was)? Is there a list somewhere of the supported or unsupported callbacks? Are there any other guidelines? Is there any handy debugging mode built into the engine to help? What does the exernal do? Perhaps it could be rewritten in native MetaTalk -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 2.0: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
