MC IDE v2.6b12 posted

Fri Dec 30 12:51:20 CST 2005

Thanks Richard.

I've downloaded and installed.  Everything looks great so far.  Just 
one thing:  Should I be concerned with the note which appears warning 
me the Tools stack, version 2.6.1 does not match the engine version 
which is 2.6.6?

Thanks,

Ray Horsley
Developer, LinkIt! Software

On Dec 30, 2005, at 12:34 AM, Richard Gaskin wrote:

> The latest build of the MC IDE is now available at:
> <http://groups.yahoo.com/group/MC_IDE/files/Latest%20Test%20Version/>
>
> Among other enhancements, this build include an updated Variable 
> Watcher from Ken Ray, and the latest libURL from Dave Cragg.
>
> Thanks to all for their contributions to this build.
>
>
> Earlier, Wilhelm Sanke wrote:
>> 1. When the MC IDE is started, stack "mctools" appears to have been 
>> be loaded twice. This was mentioned by Tariel Gogoberidze 
>> <tariel at mac.com> on Sept 1, 2005:
>>> Also, one kind of strange thing I just noticed in my copy of IDE.
>>>
>>> In freshly launched MC if I type in msg box "put the stacks", it puts
>>> mctools.mc twice
>> I see this this happening here, too. Maybe the double-loaded stack is 
>> the cause underlying the nex item:
>
> I was unable to reproduce this.  Please let me know if this recurs 
> with the latest build, and if so what OS and engine version.
>
>
>> 2. Launching the IDE from a CD you get a warning "Cannot build a 
>> Plugins folder" - or the like. If you press the "skip" button, the 
>> same warning is repeated. Only after after the second "skip" the IDE 
>> is started.
>> Could it be that both "mctools" stacks are involved here?
>> And maybe we could let detect the script from where the IDE is 
>> started, then in case of a CD we could skip the warnings altogether.
>> What is the cause of the double-loaded mctools stack? I think we can 
>> rule out that the stack may launch itself another time (as that could 
>> lead to an infinite loading of mctools stacks).
>
> Same as above.
>
>> Has the "home" stack been changed or is the cause the new 
>> Metacard/Revolution engine? (for another engine-related bug see 
>> below).
>
> The Home stack has not been updated since it was first made open 
> source by Dr. Raney.
>
>
>> 3. The "Find" tool comes up with "bwidth"; the "replace" tools comes 
>> up with "bwidth" for the find string and "4wDev" for the replace 
>> string. They should come up blank.
>> 4. The Standalone Builder displays "4W WebMerge Folder/WebMerge24.mc" 
>> for the stack name and "/Area 51/4W/WebMerge/wm24/dev..." for the 
>> standalone file name. They should come up without any preset entries.
>
> Mea culpa. Pardon the poor housekeeping.
>
> I belive I've cleared all old strings out in this build.  Please let 
> me know if you find any remaining anomalies.
>
>
>> 5. The Standalone Builder builds standalones according to the 
>> look-and-feel for  "OS native" even if "Windows 95" has been set in 
>> the preferences.
>> I noticed this when I build the splash stack for my "Colorpattern 
>> Toolkit" (<http://www.sanke.org/Software/PatternToolkitWin.zip>) and 
>> tested it with other stacks.
>> I tried to find out whether version 2.6 of the two embedded (in 
>> mctools) standalone builders was the cause, but it wasn't. Even using 
>> an older standalone builder (of MC 2.5) , but with the 2.6.6 engine, 
>> made no difference. But changing to an older engine, namely that of 
>> MC 2.5, produced a standalone with Windows look-and-feel even when 
>> the new standalone builder was being used.
>> Which means that the culprit must the new engine! I built a 
>> standalone of the same stack in the Rev IDE with "Windows emulated" 
>> checked: Same result, the produced standalone displays MacOS native 
>> features (like they appear on Windows).
>
> Do we have a confirmation that this is an engine issue?  BZ#?
>
>> 6. Width of answer dialogs
>> Also on Sept 1 Tariel Gogoberidze  had written:
>>> Great, especially because I recently noticed that  in my copy of B11
>>> IDE answer dialog can't expand it's width dynamically more than about
>>> 460 pixels, trims my forth button in half.
>> I myself noticed that one button was cut in half in the longer 
>> dialogs of my Colorpattern Toolkit (when six button were displayed), 
>> but only when OS native was checked. With "Windows" set, all buttons 
>> appear in full length, but - see item above - when the standalone had 
>> been built, it was transformed to "OS native" and the last button cut 
>> in half.
>> The Revolution answer dialogs display all 6 buttons in full length 
>> irrespective of the chosen look-and-feel. However, I do not like the 
>> overall length of the Revolution dialogs.
>
> The Ask and Answer dialogs have been substantially revised for this 
> build.  Please give 'em a whirl and let me know how they work for you.
>
>
>> 7. The case of the "placed" answer and ask dialogs
>> One thread of the discussion had ended Sept 5 with statements from 
>> Scott Rossi and Richard Gaskin:
>> Scott:
>>> >> You can of course use the available IDE dialogs: Just add the two 
>>> script
>>> >> lines I have proposed (at the right place) to them, this is what I
>>> >> normally do when a new version appears.
>>>
>>> Not when I'm delivering tools to other developers, no.  I have no 
>>> problem
>>> messing around with my own development environment but I don't want 
>>> to
>>> modify other developers' IDEs.
>>
>> and Richard:
>>> I'm a bit skittish about using properties -- how about a global named
>>> gMCAlertLoc?  When empty it uses the proposed defaults I outlined, 
>>> and
>>> when set it becomes the default location.
>>
>> I can only stress again that my proposal to add two scriptlines to 
>> the answer and aks dialogs is absolutely harmless, the "NewLoc" 
>> property is just *dormant* when not invoked and reset at once even if 
>> used. But the gained flexibiltiy is enormous on the other hand.
>> See the majority of the dialogs of the already mentioned-above 
>> "Colorpattern" stack.
>> Aren't we just discussing how to "mess around" with the IDE, to 
>> really improve it in such a way that "other developers" can benefit 
>> from it?
>> The two lines to be added are at the end of the preopenstack handlers:
>> Line 1: "if the NewLoc of this stack is not empty then set the loc of 
>> this stack to the NewLoc of this stack"
>> Line 2: "set the NewLoc of this stack to empty ".
>> There is no need to be "skittish" here, because the two lines are 
>> encapsulated in a way, they do not interfere with any other parts of 
>> the script when no "newLoc" has been set in the calling script.-
>
> Agreed, and implemented in both the Ask and Answer dialogs.
>
>> 8. We cannot display ".rev" files in the dialog for loading stacks, 
>> we have to switch to "all files" to find them finally among all other 
>> file types in the directory. The Rev IDE displays both Metacard and 
>> Rev files in the open dialog.
>> A couple of months ago I had made such a proposal for the MC IDE and 
>> had shown how to script this.
>
> This build now uses the new "answer file...with filter" syntax, with 
> support for both .mc and .rev.
>
>> 9. I found out that it is impossible to build standalones from 
>> Metacard stacks (when maintaining their extension "mc") with the Rev 
>> standalone builder. Up to now I had assumed that it has something to 
>> do with embedded dialogs or other substacks, but that is apparently 
>> not the case.
>> The other way round, building standalones in the MC IDE from rev 
>> stacks is possible even with maintaining the extension. But when 
>> selecting the file in the dialog, Rev files are not displayed (see 
>> the related issue 8. above), but you can type the stack name into the 
>> dialog, which is however less comfortable than selecting the file 
>> directly.---
>
> The new "with filter" syntax has been implemented here as well.
>
>
> Thanks again for the detailed report.
>
> Keep 'em coming -
>
> --
>  Richard Gaskin
>  Managing Editor, revJournal
>  _______________________________________________________
>  Rev tips, tutorials and more: http://www.revJournal.com
> _______________________________________________
> metacard mailing list
> metacard at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/metacard
>