further incompatibilities with Rev

[J. Landman Gay]

On 10/9/04 3:43 PM, Ken Ray wrote:

> On 10/9/04 12:19 PM, "J. Landman Gay" <jacque at hyperactivesw.com> wrote:
> 
> 
>>On 10/8/04 2:31 PM, Richard Gaskin wrote:
>>
>>
>>>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.
>>
>>Is this really new? I thought it had been around since Rev 1.0.
> 
> 
> No, Rev would just ignore it in previous versions. Only in 2.5 are they
> actually bringing up the warning dialog.

We should get them to change it back to the old behavior if we can. That 
would be the easiest solution all around.


>>>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?
>>
>>If you mean removing the resource mover, then I'm not keen on doing
>>this, as it eliminates the control we have that is the main reason we
>>use the MC IDE in the first place. I'd prefer to just continue omitting
>>these dialog stacks unless I'm building a standalone.
> 
> 
> Agreed. Although the problem *for me* is that I'm working on projects that
> need to have standalones rebuilt over and over again as the project
> continues. This means that I would have to maintain two versions of my main
> stack (or always copy it before I build it into a standalone), which is a
> real pain in the ***.

I understand, since I just ran into this identical problem today. I 
ended up making a duplicate stack with resources embedded, which isn't 
optimal since like you I am going to have to rebuild this app many times.

I can see some advantages to changing the standalone builder to allow 
resources to be embedded during a build -- but I'd like to keep the old 
resource mover intact as it is now, and have the resources as an extra 
option in the SB. However, I'm not in favor of turning the current lean 
and mean SB into something bloated and complex. If these IDE 
idiosyncracies continue, I'm afraid of ending up with something far 
different than the IDE we are used to.

> 1) Stack with resources sent to someone who opens it in Rev:
> 
>      This sounds to me to be a relatively unique/rare circumstance because
> one could just as easily create a standalone and send it to them and avoid
> the issue (although it would add significantly to the download). In those
> circumstances, perhaps having a "strip resources" utility that can be run on
> our stacks prior to sending them out might do the job.

The current Resource Mover will strip out resources, actually.

The above is exactly the situation I'm in; the client needs to work with 
the stack itself in Revolution, while also distributing the standalone 
version to others. Rev wouldn't build the standalone correctly, so I had 
to do it in MC. Thus, the duplicate stack with embedded resources was 
needed. Pain in the rear.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com