Ian McLean wrote:
> I have been using MPLAB 6.10 for a few weeks only.  Not game yet to
> try 6.12 as it is not yet complete.  I only use it for coding and
> assembly of MPASM, and my observations are:
>
> a) I like the context colouring, except MPLAB gets it screwed up from
> time to time, particularly with literals.  Example 'movlw 0Ah' shows
> the '0Ah' in red as it should, but 'movlw 0Dh' shows the '0D' in
> black, and the 'h' in purple.  Seems to compile properly, but seeing
> things like this makes me paranoid that the assembler too might get
> it mixed up.  Duh!  Is this Microchip's way of saying "be more
> consistent with your literal definitions" ?
>
> b) Had to go and fix much of my indentation after changing tabs to
> spaces.
>
> c) Why, oh why, oh why has Microchip STILL not given us the ability
> to split a code window?  I was really hoping they would have put this
> in :(  I have a few projects with upwards of 10,000 lines of code in
> them, and would really like to be able to split a window so, for
> example, I can see my register bit assignments at the top of code
> whilst working way deep down somewhere else using them.  I asked for
> it after version 5 but seems I was completely ignored - which is why
> I attempted to use Visual Studio as my IDE, but that is not a good
> option because you do not get the output window so cannot click on
> errors to "go to that line".

The best way that I've found to "fix" these problems is to use
UltraEdit32.  It's the best editior that I've ever seen or used.  Of
course the clicking on the error and going to the line problem will
still remain.  :-(

> d) It does not pick up the processor option from code.  First compile
> of my f877 code generated a zillion errors and froze the IDE (!)
> because the compiler was set for an 18C series chip.  I was hoping
> that Microchip may have done something to pick the processor from the
> include line in code.  I suppose this is asking a bit too much -
> except that even a zillion errors shouldn't freeze the IDE :(

Yes that is lame isn't it?

> e) Cannot see much other difference seeing as I only use it for
> coding/assembly except support for some newer PIC's.

Another thing that I don't like about the new MPLAB is the way that it
shrinks the "Output" window every time that I initiate a build.  I then
have to maximize it again after the build is finished to examine the
output messages.  I find this to be very annoying, since I don't use
their editor and only need to see the error messages.  Not to mention
the amount of time it takes to start up.

I also like to edit my code on a black background using a certain syntax
colorization scheme, and that just doesn't seem possible with MPLAB.
Long live UltraEdit32, it's truly the best text editor there is.

RANT:
All in all, I am very dissappointed in this tool.  We waited a long time
for a "windows" version, and this is all they could muster up?  IMO,
they should probably just give up and distribute code-warrior.  Given
the number of years it took to get this together, one can only wonder
how much longer it will be before they get it right, if ever.

Why can't MPASM deal with "unix" type files (no CR just LF seperators)?
They look fine in MPLAB's editor window, but MPASM has a caniption fit
about it and generates obtuse error messages.  :-(
/RANT

michael brown

"In the land of the blind, he who has one eye is king"

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu