further incompatibilities with Rev

FlexibleLearning at aol.com FlexibleLearning at aol.com
Sat Oct 9 17:11:23 EDT 2004


I hope this does not read as a rant, but when Rev messes with  long-standing  
behaviours it is more than a little disquieting, even an  increasing concern, 
especially when no mention of such changes is made.  Maybe they feel that Rev 
owes nothing to MC-users who should be 'converted' by  now anyway. You can 
add this incompatibility to the new cipherNames tokens which  requires a rev 
library which looks like the start of a trend of implementing  terms that are not 
engine-supported. I had understood Revolution to be a  font-end only... If it 
is not so, I am worried at long term prospects.
 
To Richard's question about resource moving:
How would integrating a ResourceMover into the standAloneBuilder differ  from 
using it as a separate utility stack? Are we talking about stacks, or  
standAlones? I think the short answer is to roll your own as usual using a  
different nameSpace, and include MC IDE tech notes identifying issues of  divergeance.
 
/H


-------------------------------------------------------------------
A new incompatibility has arisen between the 14-year-old MC IDE and the  
latest version of Rev:  If you've used MC's Resource Mover to copy the  
answer dialog, ask dialog, etc. into your stack, when you hand that  
stack to a client to open in Rev they're greeted with an error dialog  
warning them that stacks with those names are already in  memory.

While we've already spent more time than I would prefer  accomodating 
Rev's new behaviors, it may be simpler for us to simply accept  being 
forced into doing the extra work of integrating the Resource Mover  with 
the Standalone Builder as Rev does to accomodate its new  behaviors.

What are the pros and cons of copying resources only into  standalones?

Of course the long-term solution is to get rid of the  uniquely 
Transcript limitation of stack name conflicts, as requested in  
<http://support.runrev.com/bugdatabase/show_bug.cgi?id=1061>.

But  in the meantime how can we best accomodate others in our workflow 
who use  Rev?
-------------------------------------------------------------------
 


More information about the metacard mailing list