Pavel

SourceBoost v7.11 is available to download from the main download page at http://www.sourceboo...onDownload.html Change log fixed debugger watch issue when debugger incorrectly handled structs that contained pointers fixed errors in compiler code generation for comparison expressions that contained signed short vars installation now shows confirmation when MPLAB integrate and VC++ 2008 redist buttons are pressed fixed ide problem when words TODO or FIXME in the sources caused file save problems fixed BoostC++ integration into ide that was broken in 7.10 release fixed settings and

Please let us know if you find any problems in 7.11rc1. We plan to do 7.11 final release on Feb 17th. Regards, Pavel

This issue has been fixed and the fix available starting from 7.11rc1

Sorting of file names in the project window is available starting from 7.11 rc1

I can't reproduce this one. Find next always scrolls to the next match even if it's inside a folded section (the section gets unfolded) This one has been fixed and will be available in 7.11 (not rc1 but whatever comes next) As mentioned above I can't reproduce this. Scroll always works for me. The current directory in find/replace dialog is remembered between searches. So what is selected is what was used in the last find/replace operation. To navigate to project directory there is a dedicated button next to the location field (the one with dot in it). Ju

Change log: fixed ide problem when words TODO or FIXME in the sources caused file safe problems fixed BoostC++ integration into ide that was broken in 7.10 release fixed settings and build problems in several examples supplied in the installation fixed watch window for very big values for unsigned long type fixed problem when debug session wasn't closed correctly when another workspace was opened during debugging boostlink.exe renamed into boostlink_picmicro.exe installation modified to check DEP settings only if wmic.exe is present installation updated to include vc2008 redistribut

SourceBoost V7.11 release candidate 1 is available to download from http://www.sourceboost.com/CommonDownload.html Regards, Pavel

Look at the bright side. Now you are an LCD expert. Regards, Pavel

ccpr1 is defined as char for backward compatibility with other PIC types that have this register one byte long. Same approach is used for all other registers in system headers. To access 16 bit register two other variables are defined just after ccpr1. These are ccpr1l and ccpr1h that are mapped to low and high byte of the register and these are the ones you need to use. Regards, Pavel

Please post screenshot of the IDE. Regards, Pavel

We do this everywhere but must have forgotten this case. Will investigate and try to fix in the coming release (which was due by Christmas but we ran into some problems that need to get fixed before the release, sorry about the delay) Regards, Pavel

No this is no possible. Regards, Pavel

We were able to reproduce this problem. Now fixed. Fix will be available in the coming release. Regards, Pavel

I could not reproduce the problem. Here is what I did: 1. add file to an existing project 2. open it inside SourceBoost IDE 3. add some text 4. save 5. check if the changes appear in the file using an outside editor (ok) 6. do more changes in the file from inside SourceBoost IDE 7. close the file (this will make IDE ask if the changes need to be saved, answer yes) 8. check if the changes appear in the file using an outside editor (ok) Any suggestions how to reproduce the problem? Regards, Pavel

Currently it's not possible to disable .tree file generation by linker but you can try to delete this file from postbuild.bat (see the 'Build' chapter in users manual). Let us know if this works. Regards, Pavel

There was a bug in MplabX related to full re-build (in the MplabX generated makefiles it added dependency to a .mk file into nbproject/Makefile-default.mk file and re-generated this .mk file at every build) but it was fixed several months ago. Apart from that we are not aware of any other problems. Maybe you can check the makefiles generated for your project and if timestamp of the dependency file changes after every build? Can anybody else report about their MplabX build experience? Regards, Pavel

We decided to split the eeprom library for PIC18 into 2: one that uses 8 bit addressing and another that uses 16. Both will be part of 7.11 release and are attached to this post. The header file hasn't changed. Regards, Pavel eeprom.zip

We investigated this issue and it looks like there is some build problem in the eeprom library included into the 7.10 release If the same library is re-built it works as expected. I will attach an updated library from the coming 7.11 release to this thread later today when I get access to my development system. To call eeprom_write with 16 bit address just make the call with 16 bit long first call argument like: #include <system.h> #include <eeprom.h> ... //this will call eeprom_write( unsigned short, unsigned char ) eeprom_write(0x100, 0x55); //this will call eeprom_wr

Yes you can. The library takes advantage of the function overloading. The lib file contains both functions: one that uses 8 bit address and another that uses the 16 bit one but the header file only declares one of those based on the EEARDH definition. This way all external to the library code can use only one of these functions. Regards, Pavel

Me neither but I guess some do and compilers should allow this (i.e. gcc) Regards, Pavel

Yes as you correctly noted in a following post it's the linker who will report an error if a variable is defined in more than one place. This might look a bit strange but the rationale for this kind of behaviour is that the code may be structured so that an 'extern' statement will be inside a header file that is included into all source files and one of these source files will have the actual variable definition: common.h extern int n; source1.c #include "common.h" ... source2.c #include "common.h" ... source3.c #include "common.h" int n; ... We pla

Function pointer is just another kind of a variable and should behave as other variables do. So if code like this: extern int n; int n; compiles, similar code that uses function pointers should compile too: extern void (*foo)(void); void (*foo)(void); This issue will be fixed in the coming release. Regards, Pavel

The cause of this problem is in the way how IDE decides if wizard is supported by the toolsuite used for the active project. In an empty workspace there is no active project and because of this IDE disables the wizard. We have fixed this behaviour so that id there is no active project IDE will still call the BoostC wizard. The fix will be available in the coming release. Regards, Pavel

Division (as well as multiplication and remainder) is based on one of the division function defined in boostc.h and extended internally by the compiler for signed types. Regards, Pavel

We were able to reproduce the problem. Seems to be a bug. We will investigate. Regards, Pavel