Wilhelm Sanke wrote:
Unless, of course, the whole thing will be resolved by the Rev team in a
different way other than Oliver's workaround.
It might be a good idea to wait and see what happens before we put a lot
of work into revising the MC IDE. RR version 4 is still changing.
--
Jacquelin
ot;.
I tried to explain in my last post how Oliver Kenyon's solution to
bug 2217 might work with
the patched stack "RevStandaloneSettings" and the new custom
property (introduced as a workaround by Oliver), namely
"cREVKeepDevelopmentProperties".
If this property i
ed to explain in my last post how Oliver Kenyon's solution to bug 2217
might work with
the patched stack "RevStandaloneSettings" and the new custom property (introduced as a
workaround by Oliver), namely "cREVKeepDevelopmentProperties".
If this property is *not* set to true, the
t using the file "Standalone" as it was
necessary before
When you remove file "Standalone" from the "Runtime" folder - or
delete it completely - this has no longer an effect on standalone
building.
Hope this is correct and helps?
Hmmm, are you sure, that the
is no longer needed or used.
The command "Save as Standalone Application" in Menu "File" of the Rev
IDE is then sent directly to the Rev engine to build the standalone -
without using the file "Standalone" as it was necessary before
When you remove file "Stan
> For the Metacard IDE this could mean that we integrate command "set
> the cREVKeepDevelopmentProperties of this stack to true" into our
> Standalone Builder - possibly in form of a checkbox button - with
> the default setting to true.
Why on earth should anyone want to set "cREVKeepDevelopmentPr
al command "set the
cREVKeepDevelopmentProperties of this stack to true". Standalone
building in the Rev IDE with these changes is now nearly as fast as
in the MC IDE. The option of decreasing stack size by removing
development properties added by the Rev IDE could and should
On Oct 8, 2009, at 2:16 PM, J. Landman Gay wrote:
Richard Gaskin wrote:
The full sentence in which RunRev's Oliver Kenyon suggested the
need for an engine change is worth noting:
To fix the issue, we will need to make an engine change, possibly
the addition of a "repeat for each control"
;set the cREVKeepDevelopmentProperties
of this stack to true". Standalone building in the Rev IDE with these
changes is now nearly as fast as in the MC IDE. The option of decreasing
stack size by removing development properties added by the Rev IDE could
and should IMO be implemented in the
Richard Gaskin wrote:
The full sentence in which RunRev's Oliver Kenyon suggested the need for
an engine change is worth noting:
To fix the issue, we will need to make an engine change, possibly
the addition of a "repeat for each control" loop form.
So rather than something irritating, it
Wilhelm Sanke wrote:
What irritates me is that they speak of a necessary change to the
*engine*, which kind of engine is involved her? What does "(ide) engine"
mean, which - according to the engine-change log - will implement the
standalone building in dp4 and in the future. If this
nge to the
*engine*, which kind of engine is involved her? What does "(ide) engine"
mean, which - according to the engine-change log - will implement the
standalone building in dp4 and in the future. If this engine is
identical to the Revolution engine, then we - as MC-IDE users -
Hugh Senior wrote:
IF the new standAlone builder forces the inclusion of spurious
"development
properties" to each control, I for one shall not be upgrading.
Klaus answered:
"As far as I know this is NOT part of the process of building the
standalone but a scripted Rev IDE only thingie!"
AF
Hugh Senior wrote:
This is good. The less, the better.
Or as my husband says, "The less, the more". :)
I agree with you.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
> IF the new standAlone builder forces the inclusion of spurious
"development
> properties" to each control, I for one shall not be upgrading.
Klaus answered:
"As far as I know this is NOT part of the process of building the
standalone but a scripted Rev IDE only thingie!"
Jacqueline answered:
"R
rote:
Another additional remark:
I just looked at Bug report 2217 which I sent on Sept 20, 2004, five
years ago.
Report #2217 "New troubles with standalone building and players for
multi-fields stacks" is still labeled as "new"
A last commentary from my side had been added
Hugh Senior wrote:
Wilhelm:
IF the new standAlone builder forces the inclusion of spurious "development
properties" to each control, I for one shall not be upgrading.
Rev doesn't add development properties during the build (unless you
choose to include libraries), it just checks each control t
Hi Hugh,
Wilhelm:
IF the new standAlone builder forces the inclusion of spurious
"development
properties" to each control, I for one shall not be upgrading. At
present,
at least we can set the custompropertysets to remove any spurious
rev-IDE
crap if migrating a stack from RevIDE to MC-IDE
Wilhelm:
IF the new standAlone builder forces the inclusion of spurious "development
properties" to each control, I for one shall not be upgrading. At present,
at least we can set the custompropertysets to remove any spurious rev-IDE
crap if migrating a stack from RevIDE to MC-IDE, but if it become
Another additional remark:
I just looked at Bug report 2217 which I sent on Sept 20, 2004, five
years ago.
Report #2217 "New troubles with standalone building and players for
multi-fields stacks" is still labeled as "new"
A last commentary from my side had been a
ack "Testcolors 1600" in file
<http://www.sanke.org/Software/RevTestStacks.zip>:
Subject: New troubles with standalone building and players for
multi-fields stacks
The tests described below were conducted on a Windows XP machine with
2.5 GHz.
The standalone build time for my
Thanks for the clarification about a new process for standalone building
in Rev version 4.
From Richard's quote of the v4 engine change log:
In order to achieve this, it has been necessary to implement the core
operation of standalone building in the (ide) engine. This means that
22 matches
Mail list logo