I still haven't seen a compelling reason to change to CW (and I already
have
it).
I am very happy using PilRC. When I added a new form to my project, I
just cut
and pasted the controls I wanted to move to the new form. It was very
simple to
readjust the first controls location, and the others moved accordingly.
Alignment is also simple. Can CW do that ?
My gripe is that I use a DOS window and DOS EDIT (yeah, I know there are
good
editors, but I have to remember too many now & I don't want to add to
the
confusion)
A second problem is the fact that I will have to reinput all my existing
PilRC
code in graphical format if I move to CW (or one of the IDEs
suggested). Any ideas ?
Third, What about all the CW bugs I have seen on this list which will
not be fixed
until R6 ? - That will cost me $ since I've already got my free R5
update.
Can someone with CW experience give us some good (or bad) reasons ?
Regards,
Ray
Chris Antos wrote:
> > No one else seems to pick up on this, so I'll continue to beat
> >my horse into the ground: having a visual UI builder (MW Constructor)
> >has some massive advantages over a text-compilation based one
> >(PilRC). If I actually had a system that MW ran on, I'd buy it
> >immediately, as the $360 would be very quickly recouped in UI
> >development time.
>
> ack. the "massive advantages" are basically that it's wysiwyg, and that
> it's quick and easy.
>
> i use CW, but i so strongly prefer to use script-based resource compilers
> that i wrote a tool to link PilRC-generated resources into a .PRC built by
> CW.
>
> a script-based resource compiler has several advantages:
> - human readable format
> - easy localization from a single script
> - difference-based source control systems work with it
> - i have complete control over constants, macros, etc
> - i can use macros in the script files
> - i can do a search-and-replace over the entire script whenever i want to
> - i can run the script thru any arbitrary number of preprocessors that do
> whatever i want
> - i can #include scripts or headers (PilRC natively understands only a
> limited syntax for included files, but by using a preprocessor i remove that
> limitation)
> - i can position controls relatively to each other such that when i nudge
> one control, several others automatically nudge themselves as well
> - the source code to PilRC is free and so i can add arbitrary features or
> fix bugs without having to wait for an official commercial release or patch
> - and more. these are just the ones immediately off the top of my head
>
> some of these may seem unlikely, but i commonly use and rely on all of them
> (including running things thru preprocessors). it's very difficult for me
> to imagine doing serious commerical work without using script-based
> resources. obviously people do it all the time. i've been there, and i
> don't want to go back, though. YMMV.
