1. Start MC 2.5.x or 2.6.x or any version PRIOR to 2.7X!!!!!!!
2. Edit the script of card 1 of stack "home"
3. Add these lines to the script:

on preOpenStack
   put "MetaCard" && the version && the platform && "engine"\
       & cr & "Copyright © 2001 MetaCard Corporation" \
       & cr & "All Rights Reserved" into field "Copyright"
   repeat for each line l in the customKeys["preferences"] of this stack
     if the number of words in l is 1
     then do "set the" && l && "to the preferences[" & quote & l & quote & "] of
this stack"
   end repeat

########   The following lines!!
   if the version >= "2.7" then
     start using stack "mctools.mc"
     if the platform <> "MacOS" then
         open stack "mctools.mc"
     end if
     set the defaultStack to "home"
     reset cursors
   end if
########
...

4. Close the script, save the stack and
5. you are ready to use MC 2.7.x, after updating the engine inside the app
package
as described in an earlier post.

Hello friends,

here some hints on how to prepare the different MetaCard apps from the new Rev
engines:
THIS ONLY APPLIES TO REV 2.7.x!

Since I do not use OS 9 anymore, here only the hints for OS X but should work
the same
for OS 9.

1. Make 3 copies of the Metacard.app and named them "MCPPC.app", "MCIntel.app"
and
"MCUB.app". Or whatever you need for distribution.

2. Do only REPLACE the ENGINES in:

MCPPC.app/Contents/MacOS/
MCIntel.app/Contents/MacOS/
MCUB.app/Contents/MacOS/

with the corresponding engines of the the correct REV (2.7.x) engines:

-> ../Revolution Enterprise/2.7.x/Runtime/Mac OS X/PowerPC-32/Standalone.app
-> ../Revolution Enterprise/2.7.x/Runtime/Mac OS X/Universal/Standalone.app
-> ../Revolution Enterprise/2.7.x/Runtime/Mac OS X/x86-32/Standalone.app

and rename the engines to "MetaCard" there. No changing of the PLIST files
necessary.

Do NOT use the engine of Revolution itself:
-> ../Applications/Revolution Enterprise/2.7.3-gm-1/Revolution.app -> NOT!

That's all and then you can point the standalone builder to these apps and
should be able
to build working PPC/UB/Intel apps.


Best

Klaus
a.k.a Winnie the POOBAH :-)

A new version of the Variable Watcher has been posted to the Extras
folder in the Files area. A full Read Me is included, but in
additional to many bugs being squashed and having a really solid and
flexible VW, the following features have been added:

   - Added support for global arrays
   - A context menu appears when you right-click/control-click anywhere
in the VW, allowing you to change the font or size of the text in the
VW, display the Execution Contexts palette, or change the colors used
for displaying the different types of variables.
   - Allows you to click on a variable in the Script Editor, and have
the VW scroll to and hilite the variable you clicked on.

Installation instructions, release notes and version history are
included in the download.

Note: This will be the VW that will appear in the next build of the MC
IDE.

Enjoy!

Ken Ray
Sons of Thunder Software
Email: kray@...
Web site: http://www.sonsothunder.com/

--- In MC_IDE@yahoogroups.com, "Jacque" <jacque@h...> wrote:
>
> kennanray wrote:
>
> > Hey everyone - I've updated the mcTranscriptDict plugin to fix a few
> > bugs and add a few features, and it's available in the Files area for
> > download.
>
> I don't see it there. Does it take a while to show up?

It's in the "Extras" folder in the Files area.

Ken

kennanray wrote:

> Hey everyone - I've updated the mcTranscriptDict plugin to fix a few
> bugs and add a few features, and it's available in the Files area for
> download.

I don't see it there. Does it take a while to show up?

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

Hey everyone - I've updated the mcTranscriptDict plugin to fix a few
bugs and add a few features, and it's available in the Files area for
download.

The fixes are:

- Fixed but where the index list displayed on the first card was not
simply displaying "command", "property", etc., but was displaying "f",
"fu", "fun", "func", etc. Previous version looked at the file names of
each XML file to get the token name and type, but some of those were
truncated, causing this bug. The new version gets the token and type
from inside the file.

- Fixed bug where the card for "abbreviated keyword" was not showing
up and was accidentally deleted during the building process.

- Fixed bug where the search popup menu was displaying "Word" or
"Type" twice, and was displaying "Summary" as a choice when the
summary field is not available to be searched.

Features added are:

- Now displays tokens that are part of libraries in their own library
entries in the index list. So in addition to "command", "property",
etc., we also now have "Database Library", "XML Library", etc.

Anyway, enjoy the new version, and let me know if there are any
problems or questions.

Ken Ray
Sons of Thunder Software
Email: kray@...
Web site: http://www.sonsothunder.com/

I've uploaded a stack that will optionally remove the mctools version
check and the screen resolution check when MetaCard loads by modifying
and saving the MC Home stack. It is very careful to only remove
specific lines in the script, so if you've added code to the Home
stack's openStack handler, it will be left untouched.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the MC_IDE
group.

   File        : /Extras/MC Annoyance Remover.mc
   Uploaded by : kennanray <kray@...>
   Description : MC Annoyance Remover

You can access this file at the URL:
http://groups.yahoo.com/group/MC_IDE/files/Extras/MC%20Annoyance%20Remover.mc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

kennanray <kray@...>

Hi friends of the lean IDE,

i just got this mail from Yahoo:

yadda yadda yadda...
...NOT ACTIVE FOR LONG TIME OR LESS THAN 2 USERS...
IF YOU DO NOTHING, YOUR GROUP WILL BE DELETED IN 30
DAYS AND ALL OF YOUR GROUP'S DATA WILL BE PERMANENTLY DELETED.
yadda yadda yadda...

So i am just posting something so the group does not get deleted...

So much for free webspace ;-)


Best from germany

Klaus

Enter your vote today!  A new poll has been created for the
MC_IDE group:

Please select the choice that best
describes your use of the MC IDE:

   o It's my primary work environment
   o I jump back and forth between IDEs
   o I mostly use Rev
   o I use it only for testing engine bugs
   o I never use it; signed in here just out of curiosity


To vote, please visit the following web page:

http://groups.yahoo.com/group/MC_IDE/surveys?id=11737473

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

On 3/29/04 11:06 PM, Richard Gaskin wrote:

> Re-read Monte's message:  it seems he caught something even Raney
> overlooked (doesn't happen very often). :)

Yeah, I noticed that after I posted. I should follow my rule about
reading all messages before responding to any. ;)

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

J. Landman Gay wrote:

> On 3/29/04 8:10 PM, johnrule@... wrote:
>
>
>>Yes, I for one am interested in that. It has been very embarassing
>>to have customers ask me "Why is the version number different in the
>>properties?"...from my 'splash screen' version of course  ;-)
>
>
> The file version is one of the Windows properties that can already be
> set in the Standalone Builder's "Set windows version info..." button in
> the MC IDE. This dialog allows you to set not only the version number,
> but all the properties that Windows displays. So I don't think this
> needs to be changed in the MC IDE -- unless the engine is now doing
> something differently than before.

Re-read Monte's message:  it seems he caught something even Raney
overlooked (doesn't happen very often). :)

There are apparently two version data in the file.  The MC IDE only
changes the text one, but there's also a binary one that Monte was
referring you.

You can verify this:  in Windows, bring up the Properties window for a
standalone you've built with MC, and you'll find your version among the
info in the section at the bottom of the window, but the binary version
number is shown at the top of that window.

Monte has graciously offer to take care of that along with the icon
change -- kudos to Monte!


PS: As long as we're making fun of Microsoft, this article was
Slash-dotted this afternoon:  <http://lcamtuf.coredump.cx/strikeout/>.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

On 3/29/04 8:10 PM, johnrule@... wrote:

> Yes, I for one am interested in that. It has been very embarassing
> to have customers ask me "Why is the version number different in the
> properties?"...from my 'splash screen' version of course  ;-)

The file version is one of the Windows properties that can already be
set in the Standalone Builder's "Set windows version info..." button in
the MC IDE. This dialog allows you to set not only the version number,
but all the properties that Windows displays. So I don't think this
needs to be changed in the MC IDE -- unless the engine is now doing
something differently than before.

If I remember right, we only need to change the number of bytes in the
icon that the SB checks for (unless the new format also does something
different than the old one does.)



>
> JR
>
> --- In MC_IDE@yahoogroups.com, "Monte Goulding" <monte@s...> wrote:
>
>>>Thank you, Monte.  Your contribution will be noted in the About
>
> box.
>
>>Anytime... if you want me to actually do this then I can but I
>
> have no idea
>
>>of the process for checking ot an IDE component here...
>>
>>There's probably one other change that you might be interested in
>
> making and
>
>>that's the work I did on the binary product version and file
>
> version
>
>>numbers. Without this you will continue to get the engine numbers
>
> in the
>
>>windows file properties dialog.
>>
>>Cheers
>>
>>Monte
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
> .
>


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

> Good catch -- it seems the other info is okay, but indeed there are two
> areas labeled "File Version" and only one adopts the settings Scott
> addressed.
>
> I wonder why Scott overlooked that?  Was it always displayed as
> prominently, or is this new to XP?

Can't remember. Haven't used Windows 98 for years. I can't think why it
handn't been implemented previously. It wasn't that hard once Dar helped me
attack the endians. When I first started using MC there wasn't even a spot
to choose a document icon file in the standalone builder...

Cheers

Monte

Monte Goulding wrote:

>>I think Monte's talking about engine v2.6, which hasn't been released
>>yet.  In all earlier versions you just enter the info you want into the
>>Standalone Builder's "Windows Info" window, and after the standalone is
>>built that info will appear in the Windows Properties window.
>
> Nope... talking about older engines too with this point. Windows executables
> apparently have two product and file version numbers. One text and one
> binary. The binary ones weren't being set by either the Rev or MC standalone
> builder and unfortunately it's the binary file version that Windows displays
> prominently. To check this out you simply need to right-click on a
> standalone and pull up the version info.
>
> So what the Rev standalone builder now does is offer an interface for
> entering the 4 numbers for each of these and then uses the same 4 numbers to
> set both the text and binary fields in the exe.

Good catch -- it seems the other info is okay, but indeed there are two
areas labeled "File Version" and only one adopts the settings Scott
addressed.

I wonder why Scott overlooked that?  Was it always displayed as
prominently, or is this new to XP?

> PS Don't ask me why this duplication exists. The guy that wrote the EXE file
> format might help you there ;-)

Microsoft is like a crazy uncle you have to apologize for when you bring
a guest to holiday dinner. :)

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

> I would suggest that if we continue this conversation we please do so on
> the MetaCard list.  In a vote last August it was decided that the MC
> list would be the primary forum for IDE design issues, since it has the
> larger membership and most MC IDE users are already subscribed.

To be honest it doesn't worry me one way or the other as I don't use MC. If
your happy then I won't complain. I'll just change the substack, clone it
and send it to you as you suggest and you can work out how you want to deal
with older engines.

Cheers

Monte

Monte Goulding wrote:

> Oh... actually I think I could handle it as long as we can assume the engine
> you are pointing the standalone builder at is the same version as the
> running one...

The goal is to use the same Standalone Builder UI with the same
behavior.  That is, you can point it to any engineyou need for your
desired target platform.

>>We've discussed the relative merits of breaking the IDE up into separate
>>stack files, but there were more votes for keeping it simple and
>>self-contained, and moving stacks in and out during development is easy
>>to do so it hardly matters either way.
>>
> Well... add my vote to a stack file based setup. You can keep it neat with
> folders just as well as you can with stackfiles.

Twice as many icons: two instead of one.

And additional error-checking needed for essential components.

And additional stuff (stack files) to keep track of it.

All in all simple enough, but I'm not inclined to fix what isn't broken. :)

> The advantages are obvious if you are working with multiple
  > contributors and would make it far simpler for people to
  > take ownership of components.

Development and deployment are two separate issues.

The current workflow is:

1. Someone works on a substack within the stack file
2. They either send the stack file or clone out the substack
     and send it to the poohbah
3. The poohbah does a Q/A check when folding it into the build,
     and then posts the new combined stackfile for review.

Transport of elements during development is trivial.  My focus is on the
developers who use the IDE, rather than the three or so people who
contribute content to it.   If the number of contributors grows this
could even be done over the Internet.

It matters little whether storage is in a file or a folder, but like OS
X bundles having them in a single file has its benefits.

Also, keep in mind that the next major revision to is the addition of a
Plugins menu.  This is for the benefit of both the larger Revolution
community as well as tools contributors:  by making use of the
extensibility inherent in both IDEs, enhancements can be shared freely
between them.

This carries the additional benefit of allowing a fully customized
workspace, in which you use the tools you choose and don't bother with
those you don't care about.

With plugins there is of course a folder for those parts, and in time
you'll be able to override current menu handling from plugins as well.
But in the event that the plugins folder doesn't get moved along with
the IDE file, the IDE's self-contained nature will continue to provide
good utility even without those enhancements.


I would suggest that if we continue this conversation we please do so on
the MetaCard list.  In a vote last August it was decided that the MC
list would be the primary forum for IDE design issues, since it has the
larger membership and most MC IDE users are already subscribed.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

> I think Monte's talking about engine v2.6, which hasn't been released
> yet.  In all earlier versions you just enter the info you want into the
> Standalone Builder's "Windows Info" window, and after the standalone is
> built that info will appear in the Windows Properties window.

Nope... talking about older engines too with this point. Windows executables
apparently have two product and file version numbers. One text and one
binary. The binary ones weren't being set by either the Rev or MC standalone
builder and unfortunately it's the binary file version that Windows displays
prominently. To check this out you simply need to right-click on a
standalone and pull up the version info.

So what the Rev standalone builder now does is offer an interface for
entering the 4 numbers for each of these and then uses the same 4 numbers to
set both the text and binary fields in the exe.

PS Don't ask me why this duplication exists. The guy that wrote the EXE file
format might help you there ;-)

Cheers

Monte

johnrule@... wrote:

> --- In MC_IDE@yahoogroups.com, "Monte Goulding" <monte@s...> wrote:
>
>>There's probably one other change that you might be interested in
>> making and that's the work I did on the binary product version
  >> and file version numbers. Without this you will continue to get
  >> the engine numbers in the windows file properties dialog.
>
  > Yes, I for one am interested in that. It has been very embarassing
  > to have customers ask me "Why is the version number different in the
  > properties?"...from my 'splash screen' version of course  ;-)

I think Monte's talking about engine v2.6, which hasn't been released
yet.  In all earlier versions you just enter the info you want into the
Standalone Builder's "Windows Info" window, and after the standalone is
built that info will appear in the Windows Properties window.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

Yes, I for one am interested in that. It has been very embarassing
to have customers ask me "Why is the version number different in the
properties?"...from my 'splash screen' version of course  ;-)

JR

--- In MC_IDE@yahoogroups.com, "Monte Goulding" <monte@s...> wrote:
>
> > Thank you, Monte.  Your contribution will be noted in the About
box.
>
> Anytime... if you want me to actually do this then I can but I
have no idea
> of the process for checking ot an IDE component here...
>
> There's probably one other change that you might be interested in
making and
> that's the work I did on the binary product version and file
version
> numbers. Without this you will continue to get the engine numbers
in the
> windows file properties dialog.
>
> Cheers
>
> Monte

> > What are you doing about maintaining IDE support for older engines? I'd
> > suggest making the Standalone Builder a separate stackFile so
> you can offer
> > the current one and the one I modify for download.
>
> Historically, each IDE version was tied to a specific engine release.
> Swapping IDEs is not difficult; most folks don't even bother, just
> keeping a separate copy for each build.
>
> But there is merit in allowing the new open source IDE to be more
> universal.  I'll discuss this on the MC List. It would be a simple
> matter to just rename the old one and have it open instead when the
> engine version number is pre-2.6.

Oh... actually I think I could handle it as long as we can assume the engine
you are pointing the standalone builder at is the same version as the
running one...
>
> We've discussed the relative merits of breaking the IDE up into separate
> stack files, but there were more votes for keeping it simple and
> self-contained, and moving stacks in and out during development is easy
> to do so it hardly matters either way.
>

Well... add my vote to a stack file based setup. You can keep it neat with
folders just as well as you can with stackfiles. The advantages are obvious
if you are working with multiple contributors and would make it far simpler
for people to take ownership of components.

Cheers

Monte

Monte Goulding wrote:

> What are you doing about maintaining IDE support for older engines? I'd
> suggest making the Standalone Builder a separate stackFile so you can offer
> the current one and the one I modify for download.

Historically, each IDE version was tied to a specific engine release.
Swapping IDEs is not difficult; most folks don't even bother, just
keeping a separate copy for each build.

But there is merit in allowing the new open source IDE to be more
universal.  I'll discuss this on the MC List. It would be a simple
matter to just rename the old one and have it open instead when the
engine version number is pre-2.6.

We've discussed the relative merits of breaking the IDE up into separate
stack files, but there were more votes for keeping it simple and
self-contained, and moving stacks in and out during development is easy
to do so it hardly matters either way.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

> >>Thank you, Monte.  Your contribution will be noted in the About box.
> >
> >
> > Anytime... if you want me to actually do this then I can but I
> have no idea
> > of the process for checking ot an IDE component here...
> >
> > There's probably one other change that you might be interested
> in making and
> > that's the work I did on the binary product version and file version
> > numbers. Without this you will continue to get the engine numbers in the
> > windows file properties dialog.
>
> If you would like to make the change it would be very generous of you
> and much appreciated.  You can work with the latest release build in the
>   Yahoo Group file repository.
>
> The only other changes in progress at the moment are for a plugins menu
> (you'll see some more recent review builds we've been playing with), but
> those changes can easily be moved into the master once their finalized,
> so if you keep your changes limited to the Standalone Builder substack
> we'll be in great shape.
>

What are you doing about maintaining IDE support for older engines? I'd
suggest making the Standalone Builder a separate stackFile so you can offer
the current one and the one I modify for download.

Cheers

Monte

Monte Goulding wrote:

>>Thank you, Monte.  Your contribution will be noted in the About box.
>
>
> Anytime... if you want me to actually do this then I can but I have no idea
> of the process for checking ot an IDE component here...
>
> There's probably one other change that you might be interested in making and
> that's the work I did on the binary product version and file version
> numbers. Without this you will continue to get the engine numbers in the
> windows file properties dialog.

If you would like to make the change it would be very generous of you
and much appreciated.  You can work with the latest release build in the
   Yahoo Group file repository.

The only other changes in progress at the moment are for a plugins menu
(you'll see some more recent review builds we've been playing with), but
those changes can easily be moved into the master once their finalized,
so if you keep your changes limited to the Standalone Builder substack
we'll be in great shape.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

> Thank you, Monte.  Your contribution will be noted in the About box.

Anytime... if you want me to actually do this then I can but I have no idea
of the process for checking ot an IDE component here...

There's probably one other change that you might be interested in making and
that's the work I did on the binary product version and file version
numbers. Without this you will continue to get the engine numbers in the
windows file properties dialog.

Cheers

Monte

Monte Goulding wrote:
>>Has anyone successfully used the new RunRev engine that has the
>>larger icon compatibility? I imagine that all we need to do change
>>the size limitation now in the MC IDE...correct?
>
>
> Yep ;-) I wrote the code that replaces them in the engine.
>
> Actually it's rather complex because it seems there's no standard in what
> order the image formats are saved in and the engine needs them in a specific
> order. So this involved parsing the ico file format, extracting the
> individual bitmaps then reordering them.
>
> I've included the function below (watch out for wrapping). It throws
> comprehensive error messages too and I use these both when building the
> standalone and choosing the file.
>
> You will also need to find out where in the standalone builder the icon data
> is stored and put char 151 to -1 of the rev sample icons into each.
>
> Cheers
>
> Monte

Thank you, Monte.  Your contribution will be noted in the About box.

--
   Richard Gaskin
   Fourth World Media Corporation
   Developer of WebMerge: Publish any database on any Web site
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com


> -- This script parses an ICO file and reorders it's bitmaps to the required
> order for the
> -- Revolution exe. If the icons are changed in the Revolution exe then this
> script may
> -- need to be altered.
>
> constant kIconImageBytes = "296,1384,744,2216,1640,3752,1128,4264,9640"
>
> function revGetIcoFile pFile
>   local
> tReserved,tType,tCount,tWidth,tHeight,tColorCount,tPlanes,tBitCount,tBytesIn
> Res,\
>
> tImageOffset,tIcon,tWidthA,tHeightA,tBytesInResA,tDataA,tICOFile,tReturn,tMi
> ssingFormats,tNum,tRemove
>   put url ("binfile:"&pFile) into tICOFile
>   if the result is not empty then
>     throw "Standalone: Can't open Windows icon file."
>   end if
>  put char 1 to 6 of tICOFile into tHead
>   if not littleEndian() then
>     put char 2 of tHead&char 1 of tHead&char 4 of tHead&char 3 of tHead&char
> 6 of tHead&char 5 of tHead into tHead
>   end if
>   get binaryDecode("S3",tHead,tReserved,tType,tCount)
>   delete char 1 to 6 of tICOFile
>   repeat with tIcon=1 to tCount
>     put char 1 to 16 of tICOFile into tEntry
>     if not littleEndian() then
>       put char 1 to 4 of tEntry&char 6 of tEntry&char 5 of tEntry&char 8 of
> tEntry&\
>           char 7 of tEntry&char 12 of tEntry&char 11 of tEntry&char 10 of
> tEntry&char 9 of tEntry&\
>           char 16 of tEntry&char 15 of tEntry&char 14 of tEntry&char 13 of
> tEntry into tEntry
>     end if
>     get
> binaryDecode("C4S2I2",tEntry,tWidth,tHeight,tColorCount,tReserved,tPlanes,tB
> itCount,tBytesInRes,tImageOffset)
>     if tIcon=1 then put tImageOffset-1 into tRemove
>     put tImageOffset-tRemove into tImageOffsetA[tIcon]
>     put tWidth into tWidthA[tIcon]
>     put tHeight into tHeightA[tIcon]
>     put tBytesInRes into tBytesInResA[tIcon]
>     delete char 1 to 16 of tICOFile
>   end repeat
>   put the length of tICOFile+1 into tImageOffsetA[tCount+1]
>   repeat with tIcon=1 to tCount
>     put char tImageOffsetA[tIcon] to tImageOffsetA[tIcon+1]-1 of tICOFile
> into tDataA[tBytesInResA[tIcon]]
>   end repeat
>   repeat for each item tBytes in kIconImageBytes
>     if tDataA[tBytes] <> "" then
>       put tDataA[tBytes] after tReturn
>     else
>       switch tBytes
>       case 296
>         put "16 color 16 x 16 pixels"&cr after tMissingFormats
>         break
>       case 1384
>         put "256 color 16 x 16 pixels"&cr after tMissingFormats
>         break
>       case 744
>         put "16 color 32 x 32 pixels"&cr after tMissingFormats
>         break
>       case 2216
>         put "256 color 32 x 32 pixels"&cr after tMissingFormats
>         break
>       case 1640
>         put "16 color 48 x 48 pixels"&cr after tMissingFormats
>         break
>       case 3752
>         put "256 color 48 x 48 pixels"&cr after tMissingFormats
>         break
>       case 1128
>         put "Windows XP (32 bit color) 16 x 16 pixels"&cr after
> tMissingFormats
>         break
>       case 4264
>         put "Windows XP (32 bit color) 32 x 32 pixels"&cr after
> tMissingFormats
>         break
>       case 9640
>         put "Windows XP (32 bit color) 48 x 48 pixels"&cr after
> tMissingFormats
>         break
>       end switch
>     end if
>   end repeat
>   delete char -1 of tMissingFormats
>   if tMissingFormats <> "" then
>     if the number of lines of tMissingFormats = 1 then
>       put "1 required image format:" into tNum
>     else
>       put the number of lines of tMissingFormats&" required image formats:"
> into tNum
>     end if
>     throw "Standalone: The icon file "&pFile&cr&"does not include
> "&tNum&cr&cr&tMissingFormats
>   end if
>   return tReturn
> end revGetIcoFile
>
> function littleEndian
>   return charToNum(char 1 of binaryEncode("S",1)) = 1
> end littleEndian
>
>
>

>
> Has anyone successfully used the new RunRev engine that has the
> larger icon compatibility? I imagine that all we need to do change
> the size limitation now in the MC IDE...correct?

Yep ;-) I wrote the code that replaces them in the engine.

Actually it's rather complex because it seems there's no standard in what
order the image formats are saved in and the engine needs them in a specific
order. So this involved parsing the ico file format, extracting the
individual bitmaps then reordering them.

I've included the function below (watch out for wrapping). It throws
comprehensive error messages too and I use these both when building the
standalone and choosing the file.

You will also need to find out where in the standalone builder the icon data
is stored and put char 151 to -1 of the rev sample icons into each.

Cheers

Monte

-- This script parses an ICO file and reorders it's bitmaps to the required
order for the
-- Revolution exe. If the icons are changed in the Revolution exe then this
script may
-- need to be altered.

constant kIconImageBytes = "296,1384,744,2216,1640,3752,1128,4264,9640"

function revGetIcoFile pFile
   local
tReserved,tType,tCount,tWidth,tHeight,tColorCount,tPlanes,tBitCount,tBytesIn
Res,\

tImageOffset,tIcon,tWidthA,tHeightA,tBytesInResA,tDataA,tICOFile,tReturn,tMi
ssingFormats,tNum,tRemove
   put url ("binfile:"&pFile) into tICOFile
   if the result is not empty then
     throw "Standalone: Can't open Windows icon file."
   end if
  put char 1 to 6 of tICOFile into tHead
   if not littleEndian() then
     put char 2 of tHead&char 1 of tHead&char 4 of tHead&char 3 of tHead&char
6 of tHead&char 5 of tHead into tHead
   end if
   get binaryDecode("S3",tHead,tReserved,tType,tCount)
   delete char 1 to 6 of tICOFile
   repeat with tIcon=1 to tCount
     put char 1 to 16 of tICOFile into tEntry
     if not littleEndian() then
       put char 1 to 4 of tEntry&char 6 of tEntry&char 5 of tEntry&char 8 of
tEntry&\
           char 7 of tEntry&char 12 of tEntry&char 11 of tEntry&char 10 of
tEntry&char 9 of tEntry&\
           char 16 of tEntry&char 15 of tEntry&char 14 of tEntry&char 13 of
tEntry into tEntry
     end if
     get
binaryDecode("C4S2I2",tEntry,tWidth,tHeight,tColorCount,tReserved,tPlanes,tB
itCount,tBytesInRes,tImageOffset)
     if tIcon=1 then put tImageOffset-1 into tRemove
     put tImageOffset-tRemove into tImageOffsetA[tIcon]
     put tWidth into tWidthA[tIcon]
     put tHeight into tHeightA[tIcon]
     put tBytesInRes into tBytesInResA[tIcon]
     delete char 1 to 16 of tICOFile
   end repeat
   put the length of tICOFile+1 into tImageOffsetA[tCount+1]
   repeat with tIcon=1 to tCount
     put char tImageOffsetA[tIcon] to tImageOffsetA[tIcon+1]-1 of tICOFile
into tDataA[tBytesInResA[tIcon]]
   end repeat
   repeat for each item tBytes in kIconImageBytes
     if tDataA[tBytes] <> "" then
       put tDataA[tBytes] after tReturn
     else
       switch tBytes
       case 296
         put "16 color 16 x 16 pixels"&cr after tMissingFormats
         break
       case 1384
         put "256 color 16 x 16 pixels"&cr after tMissingFormats
         break
       case 744
         put "16 color 32 x 32 pixels"&cr after tMissingFormats
         break
       case 2216
         put "256 color 32 x 32 pixels"&cr after tMissingFormats
         break
       case 1640
         put "16 color 48 x 48 pixels"&cr after tMissingFormats
         break
       case 3752
         put "256 color 48 x 48 pixels"&cr after tMissingFormats
         break
       case 1128
         put "Windows XP (32 bit color) 16 x 16 pixels"&cr after
tMissingFormats
         break
       case 4264
         put "Windows XP (32 bit color) 32 x 32 pixels"&cr after
tMissingFormats
         break
       case 9640
         put "Windows XP (32 bit color) 48 x 48 pixels"&cr after
tMissingFormats
         break
       end switch
     end if
   end repeat
   delete char -1 of tMissingFormats
   if tMissingFormats <> "" then
     if the number of lines of tMissingFormats = 1 then
       put "1 required image format:" into tNum
     else
       put the number of lines of tMissingFormats&" required image formats:"
into tNum
     end if
     throw "Standalone: The icon file "&pFile&cr&"does not include
"&tNum&cr&cr&tMissingFormats
   end if
   return tReturn
end revGetIcoFile

function littleEndian
   return charToNum(char 1 of binaryEncode("S",1)) = 1
end littleEndian

Has anyone successfully used the new RunRev engine that has the
larger icon compatibility? I imagine that all we need to do change
the size limitation now in the MC IDE...correct?

The 'Windows XP' theme is nice, but a little flaky I think. Many
native objects 'flash' (especially tabs) when you are moving the
mouse...

JR

Can someone point me to where they could be archived?

Seem to remember someone was kind enough to do this?

This messages is being copied to both the MetaCard list and the MC_IDE group
at Yahoo to update folks about the IDE and to ask the question:  do we need
two mailing lists?

While Yahoo Groups require membership in a group in order to access its
files, I hadn't intended to suggest that we also use the mailing list that
comes with the group to augment/displace the conversation on the existing
MetaCard list.  If I recall correctly, when we took an informal poll of the
topic in the MetaCard list back in August it seemed that most folks
preferred to keep discussion of the MetaCard IDE on the main list.

I have no objection to using the mailing list at the MC_IDE Group if it's
useful, but since we're all subscribed to MetaCard list there may be merit
in keeping the discussion there as much as possible.  For myself, to
minimize duplicate posts in people's In Boxes while reaching the most MC IDE
users, going forward I'll post just to the MetaCard list unless there's a
compelling reason to use the MC_IDE group list that I may have overlooked.


On the status of the MC IDE:

It took us a while to iron out licensing and stuff, but we finlly have an
initial open source release of the MC IDE.

Looking ahead we see two camps forming:  those who say "The MC IDE must
change" and those who say "The MC IDE must remain the same."  As my
grandpappy used to say, "When faced with two compelling options, the earnest
designer finds a way to choose both."  :)

So here's my proposal for the next set of changes to the MC IDE:

Regardless of whatever other changes which might be made, any future options
can, and arguably should, include the addition of a Plugins menu.

I think it would be easier to use it as a main menu in the menubar as
opposed to a submenu in the Tools menu, but if there's a reason that
wouldn't be a good idea we should discuss it.

As RunRev's marketing continues to expand the Rev audience, I think it makes
sense to implement a Plugins menu in a way which is compatible with Rev
plugins and would encourage developers to use methods that allow a plugin to
be used in the Rev IDE also.  Since a plugin is just a stack and a Plugins
menu simply a way to open the stack, this shouldn't be too hard. :)

Keeping with the spirit of MC's engine-centric focus, I would propose that
we use the built-in style property of stacks to govern mode, with the
default being modeless unless you hold down the Option key (Mac) or Alt key
(Win) in which case it opens as toplevel so it can be easily modified.  If
you want your plugin to be a palette just set the style and save it.  We
could just as well use palette as the default - opinions?

The Rev IDE provides other custom properties for plugins, and I think it
makes sense to support the style property for those plugins that already
have it.  Other IDE-specific custom properties, such as those that register
a plugin for custom IDE messages, can be supported as an option settable in
a Plugins Manager window, which would be off by default to keep the message
path as clean and simple as possible.

While the mechanism for custom IDE messages like revSelectedObjectChanged
can be easily supported, for simplicity I would encourage the use of
frontscripts to handle messages directly, so long as we all play nice and
maintain the good habit of always passing system messages.

Once we have a Plugins menu in place you can mix and match your favorite
editing components without bothering with wacky stuff like my UmbrellaMan
tool. :)  We can play around with those and start a duscussion of candidates
for inclusion in the main distribution, possibly including some directly in
mctools.mc.  I'm anxious to see what Ken and Hugh are cooking up with their
script library, and Scott Rossi has some good ideas about a resize tool....

I'm game for implementing a first pass at a Plugins menu and posting it for
your review, but I should warn you that I won't be able to get back to the
IDE again until after the Rev Seminar at MacWorld on Jan. 9 & 10
<http://www.runrev.com/macworldschedule.html>.  So if one of you has time
and energy to dig into that before then that would be cool but we should
probably coordinate it on the MetaCard list to avoid duplication of effort.
If not, I'll be able to resume work on the IDE on the 11th.

In the meantime you can always trade plugins easily in RevNet, so if you
want to extend IDEs you can start yesterday -- all you need for a plugin is
a stack file and a way to open it. :)


Notes about plugin design:

There's not much to it since it's just a stack file, but there are a few
basics worth keeping in mind with any IDE components:

- Pass system messages.
   Never assume your plugin will be last in line; any library or
   backscript inserted after yours may need that message.  This
   is especially important with frontscripts, because if they
   don't pass a message nothing in the user's stack will get it
   either.

- Keep it simple.
   Most plugins do one thing really well.  There may be good
   reason to do something deep like Geoff Canyon did with his
   Navigator tool, but usually the pugins people will enjoy
   most often are the simple gems that shine at one specific
   task.  Specialization is not just for insects. :)

- Restore any changed global properties.
   If you change global properties, save them first and restore
   those values again as soon as possible before your routine
   exits. You never know what values a developer might be relying
   on for global properties, or when.

- Make it self-contained.
   Reliance on IDE-specific features may limit your tool's
   audience, and with IDEs being in a process of continual
   improvement this may help prevent having to update your
   tool each time an IDE changes.

- Frontscripts are your friend.
   You can insert them when your stack opens and remove them
   when it closes and you get access to all messages sent to
   any object.  Very handy -- just be sure to pass such messages
   when you're done with them.

- Write for explicitVars.
   A developer using your tool may be working with the
   explicitVariables global property set the true.  If
   you leave it on as you write plugins you can catch
   any undeclared variables before your users does.

- Test.
   You know how it goes.


Side note about messges: If you're making anything that responds to the
selectedbjectChanged message you might want to consider using the "message
buffering" technique used in 4W Props (downloadable from
<http://www.fourthworld.com/rev/index.html>).  This method allows palettes
to appear much more responsive when updating their UIs after user selection
changes; keep MC's Inspector, Colors, and Font palettes open and drag-select
around 50 objects and you'll see what I mean. :)


That's more than enough for now. I gotta get back to work wrapping up
year-end projects and preparing for the Rev seminar.  Hope to see you folks
in SF....

--
  Richard Gaskin
  ___________________________________________________________
  Ambassador@...       http://www.FourthWorld.com
  Tel: 323-225-3717                       AIM: FourthWorldInc