Tam, now that you mention it, you are correct. The initial versions of the 
BETAs went out without any time expiring, and the first versions of the 
official releases went out w/ 3 month expiration periods. I did that so 
people could have more time to evaluate, which is the same rationale I am 
considering 45 or 60 day eval period right now.

At 05:42 PM 6/24/2003 +0000, Tam wrote:
>Richard,
>
>It is good to see that you are at least considering... extending the
>trial periods.
>
>I did not pluck my statements out of the air though, I did have
>ICC430 running on my PC together with NoICE for much longer than the
>30-days you suggest (perhaps not exactly 3 months, but since it was
>going strong after a couple, I did assume and state, that it was
>three months). Without a crack!!
>
>Tam.

// richard <http://www.imagecraft.com> 
<http://www.dragonsgate.net/mailman/listinfo>
On-line orders, support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all previous 
replies in your msgs. ] 

Richard,

It is good to see that you are at least considering... extending the 
trial periods.

I did not pluck my statements out of the air though, I did have 
ICC430 running on my PC together with NoICE for much longer than the 
30-days you suggest (perhaps not exactly 3 months, but since it was 
going strong after a couple, I did assume and state, that it was 
three months). Without a crack!!

Tam.


--- In msp430@msp4..., "Richard F. Man" <richard@i...> wrote:
> At 03:55 PM 6/24/2003 +0100, Paul Curtis
wrote:
> >Correct me if I'm wrong, but basic research suggests that 
ImageCraft
> >offer neither 90 day nor 3-month evaluations. 
All MSP430 compiler
> >vendors offer what is becoming an industry standard 30 elapsed days
> >evaluation and have done so for as long as I care to remember.
> >...
> 
> This is correct. Our demo is fully functional for 30 days, although 
we (and 
> sounds like everyone else), extensions on
requests. Once a customer 
who 
> made a purchase mentioned that he used the demo
for about 4 months 
and I 
> asked him how he managed that (w/o using a crack),
and he said he 
just kept 
> asking me for extensions :-)
> 
> Having said that though, we may consider going to a 45 day or 60 
day demo 
> in the near future.
> 
> 
> // richard <http://www.imagecraft.com> 
> <http://www.dragonsgate.net/mailman/listinfo>

At 03:55 PM 6/24/2003 +0100, Paul Curtis wrote:
>Correct me if I'm wrong, but basic research
suggests that ImageCraft
>offer neither 90 day nor 3-month evaluations.  All MSP430 compiler
>vendors offer what is becoming an industry standard 30 elapsed days
>evaluation and have done so for as long as I care to remember.
>...

This is correct. Our demo is fully functional for 30 days, although we (and 
sounds like everyone else), extensions on requests. Once a customer who 
made a purchase mentioned that he used the demo for about 4 months and I 
asked him how he managed that (w/o using a crack), and he said he just kept 
asking me for extensions :-)

Having said that though, we may consider going to a 45 day or 60 day demo 
in the near future.


// richard <http://www.imagecraft.com> 
<http://www.dragonsgate.net/mailman/listinfo> 

Hi Paul,

I was merely quoting Tam's statements, not asserting anything myself.

Take care,
Kris

> Correct me if I'm wrong, but basic research
suggests that ImageCraft
> offer neither 90 day nor 3-month evaluations.  All MSP430 compiler
> vendors offer what is becoming an industry standard 30 elapsed days
> evaluation and have done so for as long as I care to remember.
>
> -- Paul.
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>

I would like to vote that this thread is ridiculous, obnoxious and
off-topic.  I have followed it from the beginning and still have absolutely
no idea what Tam is so upset about.  I am beginning to suspect that this
diatribe may be actually intended for his/her boss, to justify delays at
work.  I know I'm an extreme cynic but I can see no other reason to blow up
and drag out such a silly little thing.  Didn't this all start with a very
minor annoyance like having to reposition windows or something?  And wasn't
that addressed directly by a rapid response from the vendor?  Sheesh!  And
to preempt any more ridiculous accusations: I don't have any financial
relationship to the vendor being "discussed" either.  I'd just
like to
enter my vote that we move on already...

--Bruce

> -----Original Message-----
> From: Tam [mailto:embedded1@embe...]
> Sent: Tuesday, June 24, 2003 7:13 AM
> To: msp430@msp4...
> Subject: [msp430] Re: Crossworks for MSP430 - Mindful
>
>
> Thanks for your input Kris.
>
> Since you clearly state that your company has a genuine interest in
> RAL's success, I can't say that I was at all suprised by your
biased
> views.
>
> Unfortunately, the following OFFICIAL BUG LIST means that there are
> people tearing their hair out wondering why their logic is failing
> them.
>
> Before the list though. I can't see how you can 'assume'
that it took
> me 28 days to realise the fault.
>
> To enlighten you, part of this debate is about RAL not making their
> stance clear upon their prospective buyers' initial display of
> interest.
>
> As I have already said, it isn't clear from RAL's web site or
from
> discussion with them until in my case, I made a apayment that the
> evaluation copy which was being evaluated on that basis was the final
> product.
>
> Since you have worked with RAL for so long, perhaps you would like to
> point to me where on their web-site or any of their documentation,
> this is nmade clear. So, I suspect that there is some sort of
> misleading occurring!
>
> Finally. Nobody claimed that the bug I highlighted was holding back
> my project. But if you read the follong bug-list, you can imagine
> that there are a lot of people out there who are facing exactly that
> scenario.
>
> The next version of CrossStudio, God knows when it is due, RAL will
> not say, apparently has addressed these issues, but surely, thta is a
> bit too late for those who are suffering from those side effects.
>
>
> Here is that bug list: And trust me, these have been worded so
> carefully that they almost sound like benefits. But in fact is what
> is missing from the present release.
>
> T.
>
>
>
> Changes in Release 1.1
>
> Compiler
>
> Added binary constants which are written with a leading 0b, e.g.
> 0b1010 is 10 decimal. Binary constants are signalled with a warning
> when the -ansi command line option is given. The C preprocessor also
> supports binary constants.
> Corrected a problem in the switch statement as in some cases the
> 1.0.0 compiler would destroy the contents of a register used in the
> _expression.
> The long double type is now treated identically to the double type
> when Treat 'double' as 'float' is set to Yes.
> Single-bit bitfield manipulation and access now generates much denser
> code.
> Correctly implemented the __monitor function attribute to support
> Salvo from Pumpkin, Inc.
> Fixed a corruption problem on return when a multi-register value is
> allocated to coincide with the function return registers.
> The compiler now fragments the code of a function which enables
> further size reduction optimizations by the linker.
> Code generation for 0(SP) source address is now always coded using
> @SP which reduces the size of code.
> for statement generation now recognizes more special forms and codes
> appropriately.
> Narrowing and widening conversions corrected to ensure that new
> registers are used when required.
> Corrected a code generation problem compiling x *= y when -mmpy
> specified.
> Corrected a problem in the spiller which caused incorrect code
> generation on reload.
> Corrected optimization applied for x & y when y is non-constant.
> Target Interfaces
> The FET target interface now has a RAM Fill Value property that is
> used to fill the RAM before a program is downloaded. If this property
> is empty, the RAM is not filled and is left intact. You can use the
> RAM Fill Value as a watermark to see how far the stack descends
> during program execution.
> Added the PRGS430 Serial Programmer target interface to support the
> Texas Instruments PRGS430 serial programmer.
> Added the SoftBaugh Flash Replicator target interface to support the
> SoftBaugh flash replicator.
> Added the Gessler Flash Bootloader target interface to support the
> Gessler flash bootloader.
>
> Editor
>
> Added a setting to allow or disallow Cut and Copy from cutting and
> copying the current line if there is no selection.
> Added a setting to disable the numeric keypad '' and
'+' keys from
> being used as Cut and Copy (as they are in Brief).
> Added themes to the Environment Options dialog.
> Made Shift+Insert a synonym for Paste in all contexts.
> Made Ctrl+Insert a synonym for Copy in all contexts.
> Made Shift+Delete a synonym for Cut in all contexts.
> Corrected a crash when editing long lines of plain text without
> syntax highlighting.
> Corrected syntax highlighting problems with multi-line comments and
> preprocessor continuations.
> Added a VHDL syntax highlighter.
>
> Assembler
> Fixed PC-relative addressing mode offset computations.
> The C compilers preprocessor is now integrated into the assembler.
>
> Linker
>
> Corrected PC-relative addressing mode offset computations.
> User symbols can now replace symbols defined in the library; required
> to support Salvo from Pumpkin, Inc.
> Added a few micro-optimizations including branch switching.
> The section start and end symbols have been renamed to allow them to
> be accessed from C.
> The linker now supports section checksum generation using the -H
> option.
>
> Archiver
>
> The archiver no longer uses PKZIP format for its archives in order to
> be portable to Linux.
> C Library
> Added missing __int8_lsl_asgn and __int8_lsr_asgn runtime support
> routines.
> Corrected__vfprint.c which causes __vfprintf_long not to recognize "%
> l" format strings correctly.
> Added debug_scanf function.
> The debug_getx functions now take input from the debug I/O console.
> CrossStudio
> Added new project types for all SoftBaugh, Olimex, and TI boards.
> Added a new project wizard to assist in setting up a project.
> The New Folder dialog is reworked and presents example file filters.
> New projects now have the runtime startup code automatically placed
> into the project and do not use the standard startup object module.
> Solutions can now be created on drives other than the drive
> containing CrossStudio.
> Fixed incorrect reporting of file permissions on NTFS and network
> drives.
> The Evironment Options dialog now displays all properties that are
> also settable through the Properties Window.
> There is an all-new Build Properties dialog (Alt+Enter) that is much
> easier to use than the previous dialog.
> The user interface can be switched between the tabbed interface and
> an MDI-style interface.
> Project files can now be linked into other project files - most of
> the project dialogs have had to be upgraded to support this.
> Configurations now have a hidden property which causes them to be
> hidden from the configuration combo box.
> Externally built executables can be debugged.
> Solutions are now created using the new project wizard.
> Linker section placement can now be done using a file that is
> separate to the memory map file.
> Project system can create an additional output file for example S-
> Record.
> Special function registers window added which displays the registers
> defined in the memory map file used to link the project.
> Trace window improvements.
> Breakpoint dialog rehashed to support MSP430 EEM.
> Support for specifying the clock control on MSPF149 and EEM enabled
> parts.
> Exception support for PC not in FLASH range.
> Register write breakpoints.
> Installer
> The installer now installs program shortcuts correctly on
> international versions of Windows.
> The default destination directory is now correct on international
> versions of Windows.
>
>
> Known Problems
>
> We hope to fix all known problems before the next release of the
> software.
>
> Printing
>
> Printing is a problem; there are a number of problems in the
> underlying Qt toolkit that make printing a rather hit-and-miss
> affair. If it works for you, that's good, and could you let us know
> if it does. If it doesn't and produces erratic results, we'd also
> like to know about it. It would help us if you could provide the make
> and model of the printer you are using when you send in your reports.
> FET examples
> You must define the target property for these examples before
> building them.
> Help System
> The help system content is not yet complete. We are converting our
> printed matter to XHTML as an ongoing activity.
> User Interface
> Editing code templates in the Editor Properties dialog will not
> change the templates.
>
>
>
>
>
>
>
> --- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> > Hi Paul, Tamar, et al
> >
> > Thought I'd put in my 2 cents worth, as  Microbit Systems
endorses
> RAL's
> > product on their website :
> >
> >
> > 1.    This hollow comment :
> > --------------------------------
> > >> everyone else who has bought CrossStudio 1.0, realise, that
they
> are
> > >> paying 500 per seat for pretty much Beta testing it for you.
> > > I don't categorize our current tools as beta tools; they
went
> through a
> > > five-month beta period last year.
> >
> > That is correct.
> > We offered internal Beta testing to RAL and did so for a few months
> last
> > year, and I must volunteer
> > that RAL particularly conveyed as a "perfectionist vendor".
> > Things had to be pretty right before the official Beta (!) release.
> >
> > 2.    The infamous windows issue :
> > ----
> > I must say I am at a loss how Tamar overemphasises a GUI issue that
> should
> > have revealed itself
> > within 1-2 days of evaluation, not > 28 days ??
> > Furthermore, how can an "unhappy customer" claim compromised
project
> > deadlines over such
> > a minor thing ???
> >
> > I hope my opinion might be somewhat diffusing Tamar :
> > You could have spent a LOT more money, only to be faced with
> infinitely
> > bigger problems that truly
> > would have debilitated your project's progress. (I speak from
> experience
> > here).
> >
> > Lastly, maybe it might help too to know that Paul mainly dealt with
> CG (Code
> > Generator) issues, and
> > Michael more with GUI issues. (I assume that to be unchanged).
> > I refer here to your reservation about Michael responding to an
> Email you
> > sent to Paul. Perhaps this is the
> > common denominator ??
> >
> > But in any case , we are all consumers with rights, and if you're
> unhappy -
> > then that is your perogative
> > Tamar. I just wanted to make sure you base your perogative on fact
> and not
> > speculation.
> >
> > All the best,
> > Kris
> > www.microbit.com.au
> > (RFBasic has been delayed but will release in near future)
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/

Kris,

> > Before the list though. I can't see how
you can 'assume' 
> that it took 
> > me 28 days to realise the fault.
> 
> I meant the other way around (and it was a hypothesis !!).
> The popping windows issue surely would have revealed within a 
> few days of evaluation, and not need extended eval ?? (you 
> referred to Imagecraft offering 3 months, and that RAL should 
> offer so too).

Correct me if I'm wrong, but basic research suggests that ImageCraft
offer neither 90 day nor 3-month evaluations.  All MSP430 compiler
vendors offer what is becoming an industry standard 30 elapsed days
evaluation and have done so for as long as I care to remember.

-- Paul.

Hi Tam,

I'll briefly respond  to - where I think - some misapprehensions are either
on
my side, yours, or both.

> Since you clearly state that your company has a
genuine interest in
> RAL's success, I can't say that I was at all suprised by your
biased
> views.

I respect your perception/view Tam (or let's say, your perspective).
I merely tried to defend our company, because we recommend RAL's
product. Please don't misinterpret that as any bias on my side. We have NO
financial gain or loss from RAL's sales.

> Before the list though. I can't see how you
can 'assume' that it took
> me 28 days to realise the fault.

I meant the other way around (and it was a hypothesis !!).
The popping windows issue surely would have revealed within a few days
of evaluation, and not need extended eval ?? (you referred to Imagecraft
offering 3 months, and that RAL should offer so too).

> To enlighten you, part of this debate is about RAL
not making their
> stance clear upon their prospective buyers' initial display of
> interest.
> As I have already said, it isn't clear from RAL's web site or
from
> discussion with them until in my case, I made a apayment that the
> evaluation copy which was being evaluated on that basis was the final
> product.

It's hard for me to comment on that, I'm not in your position, but I
thought
that was pretty much common practice : Purchase provides you with a
non-time limited registration key ??

> Since you have worked with RAL for so long,
perhaps you would like to
> point to me where on their web-site or any of their documentation,
> this is nmade clear. So, I suspect that there is some sort of
> misleading occurring!

Perhaps a misapprehension ?

> Finally. Nobody claimed that the bug I highlighted
was holding back
> my project.

I thought you mentioned compromised project deadlines over the windows issue
?
(and having to justify to your boss)

Anyway, my posting was merely to defend your allegation that RAL's product
is non-mature
and has customers paying for Beta testing. That is a nonsense.
The other issues you mentioned in your posting are transparent to me, but
again, you as a consumer
have certain perogatives. I do not wish to be involved in those.
I hope you come around on the Crossworks IDE, I liked Beta testing it.


All the best,
Kris

Thanks for your input Kris.

Since you clearly state that your company has a genuine interest in 
RAL's success, I can't say that I was at all suprised by your biased 
views.

Unfortunately, the following OFFICIAL BUG LIST means that there are 
people tearing their hair out wondering why their logic is failing 
them.

Before the list though. I can't see how you can 'assume' that it
took 
me 28 days to realise the fault.

To enlighten you, part of this debate is about RAL not making their 
stance clear upon their prospective buyers' initial display of 
interest. 

As I have already said, it isn't clear from RAL's web site or from 
discussion with them until in my case, I made a apayment that the 
evaluation copy which was being evaluated on that basis was the final 
product.

Since you have worked with RAL for so long, perhaps you would like to 
point to me where on their web-site or any of their documentation, 
this is nmade clear. So, I suspect that there is some sort of 
misleading occurring!

Finally. Nobody claimed that the bug I highlighted was holding back 
my project. But if you read the follong bug-list, you can imagine 
that there are a lot of people out there who are facing exactly that 
scenario.

The next version of CrossStudio, God knows when it is due, RAL will 
not say, apparently has addressed these issues, but surely, thta is a 
bit too late for those who are suffering from those side effects.


Here is that bug list: And trust me, these have been worded so 
carefully that they almost sound like benefits. But in fact is what 
is missing from the present release.

T.



Changes in Release 1.1

Compiler

Added binary constants which are written with a leading 0b, e.g. 
0b1010 is 10 decimal. Binary constants are signalled with a warning 
when the -ansi command line option is given. The C preprocessor also 
supports binary constants. 
Corrected a problem in the switch statement as in some cases the 
1.0.0 compiler would destroy the contents of a register used in the 
_expression. 
The long double type is now treated identically to the double type 
when Treat 'double' as 'float' is set to Yes. 
Single-bit bitfield manipulation and access now generates much denser 
code. 
Correctly implemented the __monitor function attribute to support 
Salvo from Pumpkin, Inc. 
Fixed a corruption problem on return when a multi-register value is 
allocated to coincide with the function return registers. 
The compiler now fragments the code of a function which enables 
further size reduction optimizations by the linker. 
Code generation for 0(SP) source address is now always coded using 
@SP which reduces the size of code. 
for statement generation now recognizes more special forms and codes 
appropriately. 
Narrowing and widening conversions corrected to ensure that new 
registers are used when required. 
Corrected a code generation problem compiling x *= y when -mmpy 
specified. 
Corrected a problem in the spiller which caused incorrect code 
generation on reload. 
Corrected optimization applied for x & y when y is non-constant. 
Target Interfaces
The FET target interface now has a RAM Fill Value property that is 
used to fill the RAM before a program is downloaded. If this property 
is empty, the RAM is not filled and is left intact. You can use the 
RAM Fill Value as a watermark to see how far the stack descends 
during program execution. 
Added the PRGS430 Serial Programmer target interface to support the 
Texas Instruments PRGS430 serial programmer. 
Added the SoftBaugh Flash Replicator target interface to support the 
SoftBaugh flash replicator. 
Added the Gessler Flash Bootloader target interface to support the 
Gessler flash bootloader. 

Editor

Added a setting to allow or disallow Cut and Copy from cutting and 
copying the current line if there is no selection. 
Added a setting to disable the numeric keypad '' and '+'
keys from 
being used as Cut and Copy (as they are in Brief). 
Added themes to the Environment Options dialog. 
Made Shift+Insert a synonym for Paste in all contexts. 
Made Ctrl+Insert a synonym for Copy in all contexts. 
Made Shift+Delete a synonym for Cut in all contexts. 
Corrected a crash when editing long lines of plain text without 
syntax highlighting. 
Corrected syntax highlighting problems with multi-line comments and 
preprocessor continuations. 
Added a VHDL syntax highlighter. 

Assembler
Fixed PC-relative addressing mode offset computations. 
The C compilers preprocessor is now integrated into the assembler. 

Linker

Corrected PC-relative addressing mode offset computations. 
User symbols can now replace symbols defined in the library; required 
to support Salvo from Pumpkin, Inc. 
Added a few micro-optimizations including branch switching. 
The section start and end symbols have been renamed to allow them to 
be accessed from C. 
The linker now supports section checksum generation using the -H 
option. 

Archiver

The archiver no longer uses PKZIP format for its archives in order to 
be portable to Linux. 
C Library
Added missing __int8_lsl_asgn and __int8_lsr_asgn runtime support 
routines. 
Corrected__vfprint.c which causes __vfprintf_long not to recognize "%
l" format strings correctly. 
Added debug_scanf function. 
The debug_getx functions now take input from the debug I/O console. 
CrossStudio
Added new project types for all SoftBaugh, Olimex, and TI boards. 
Added a new project wizard to assist in setting up a project. 
The New Folder dialog is reworked and presents example file filters. 
New projects now have the runtime startup code automatically placed 
into the project and do not use the standard startup object module. 
Solutions can now be created on drives other than the drive 
containing CrossStudio. 
Fixed incorrect reporting of file permissions on NTFS and network 
drives. 
The Evironment Options dialog now displays all properties that are 
also settable through the Properties Window. 
There is an all-new Build Properties dialog (Alt+Enter) that is much 
easier to use than the previous dialog. 
The user interface can be switched between the tabbed interface and 
an MDI-style interface. 
Project files can now be linked into other project files - most of 
the project dialogs have had to be upgraded to support this. 
Configurations now have a hidden property which causes them to be 
hidden from the configuration combo box. 
Externally built executables can be debugged. 
Solutions are now created using the new project wizard. 
Linker section placement can now be done using a file that is 
separate to the memory map file. 
Project system can create an additional output file for example S-
Record. 
Special function registers window added which displays the registers 
defined in the memory map file used to link the project. 
Trace window improvements. 
Breakpoint dialog rehashed to support MSP430 EEM. 
Support for specifying the clock control on MSPF149 and EEM enabled 
parts. 
Exception support for PC not in FLASH range. 
Register write breakpoints. 
Installer
The installer now installs program shortcuts correctly on 
international versions of Windows. 
The default destination directory is now correct on international 
versions of Windows. 


Known Problems

We hope to fix all known problems before the next release of the 
software.

Printing

Printing is a problem; there are a number of problems in the 
underlying Qt toolkit that make printing a rather hit-and-miss 
affair. If it works for you, that's good, and could you let us know 
if it does. If it doesn't and produces erratic results, we'd also 
like to know about it. It would help us if you could provide the make 
and model of the printer you are using when you send in your reports. 
FET examples
You must define the target property for these examples before 
building them. 
Help System
The help system content is not yet complete. We are converting our 
printed matter to XHTML as an ongoing activity. 
User Interface
Editing code templates in the Editor Properties dialog will not 
change the templates. 







--- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> Hi Paul, Tamar, et al
> 
> Thought I'd put in my 2 cents worth, as  Microbit Systems endorses 
RAL's
> product on their website :
> 
> 
> 1.    This hollow comment :
> --------------------------------
> >> everyone else who has bought CrossStudio 1.0, realise, that they 
are
> >> paying 500 per seat for pretty much Beta
testing it for you.
> > I don't categorize our current tools as beta tools; they went 
through a
> > five-month beta period last year.
> 
> That is correct.
> We offered internal Beta testing to RAL and did so for a few months 
last
> year, and I must volunteer
> that RAL particularly conveyed as a "perfectionist vendor".
> Things had to be pretty right before the official Beta (!) release.
> 
> 2.    The infamous windows issue :
> ----
> I must say I am at a loss how Tamar overemphasises a GUI issue that 
should
> have revealed itself
> within 1-2 days of evaluation, not > 28 days ??
> Furthermore, how can an "unhappy customer" claim compromised
project
> deadlines over such
> a minor thing ???
> 
> I hope my opinion might be somewhat diffusing Tamar :
> You could have spent a LOT more money, only to be faced with 
infinitely
> bigger problems that truly
> would have debilitated your project's progress. (I speak from 
experience
> here).
> 
> Lastly, maybe it might help too to know that Paul mainly dealt with 
CG (Code
> Generator) issues, and
> Michael more with GUI issues. (I assume that to be unchanged).
> I refer here to your reservation about Michael responding to an 
Email you
> sent to Paul. Perhaps this is the
> common denominator ??
> 
> But in any case , we are all consumers with rights, and if you're 
unhappy -
> then that is your perogative
> Tamar. I just wanted to make sure you base your perogative on fact 
and not
> speculation.
> 
> All the best,
> Kris
> www.microbit.com.au
> (RFBasic has been delayed but will release in near future)

Hi Paul, Tamar, et al

Thought I'd put in my 2 cents worth, as  Microbit Systems endorses
RAL's
product on their website :


1.    This hollow comment :
--------------------------------
>> everyone else who has bought CrossStudio 1.0,
realise, that they are
>> paying 500 per seat for pretty much Beta testing it for you.
> I don't categorize our current tools as beta tools; they went through
a
> five-month beta period last year.

That is correct.
We offered internal Beta testing to RAL and did so for a few months last
year, and I must volunteer
that RAL particularly conveyed as a "perfectionist vendor".
Things had to be pretty right before the official Beta (!) release.

2.    The infamous windows issue :
----
I must say I am at a loss how Tamar overemphasises a GUI issue that should
have revealed itself
within 1-2 days of evaluation, not > 28 days ??
Furthermore, how can an "unhappy customer" claim compromised project
deadlines over such
a minor thing ???

I hope my opinion might be somewhat diffusing Tamar :
You could have spent a LOT more money, only to be faced with infinitely
bigger problems that truly
would have debilitated your project's progress. (I speak from experience
here).

Lastly, maybe it might help too to know that Paul mainly dealt with CG (Code
Generator) issues, and
Michael more with GUI issues. (I assume that to be unchanged).
I refer here to your reservation about Michael responding to an Email you
sent to Paul. Perhaps this is the
common denominator ??

But in any case , we are all consumers with rights, and if you're unhappy -
then that is your perogative
Tamar. I just wanted to make sure you base your perogative on fact and not
speculation.

All the best,
Kris
www.microbit.com.au
(RFBasic has been delayed but will release in near future)

I have nothing but the greatest respect for Paul Curtis and the Crossworks
development team.  Even though the current rev has some IDE issues, they
have been quick to acknowledge those problems and open to suggestions to
improve the product.  I am looking forward to the next revision.
 
Clyde Eisenbeis