User forums > Nightly builds

The 20 July 2006 build is out.

<< < (6/6)

MortenMacFly:
Hmmm... I still can't reproduce, too. Could you please explain your folder structure, thus give us the full path to:
- your C::B installation
- your default workspace file
- your two projects in question
Maybe this will help to enable reproducing this issue (I tried with a path like "1\2\3\4\5" but this seems to work very well).
With regards, Morten.

killerbot:
or could you provide us with a zip fiole containing your projects (with as much of your code removed as possible) and see if with those dummy projects it still crashes.

Could you also try it out with a clean CB installation (nightly in new directory and remove/rename your default.conf) ??

I had the crash exactly once, but after that I was no longer able to reproduce it. Then I did some fixes and also not able to reproduce after these fixes ;-) . The fixes I have done are these :

- constructor of cbWorkspace now initializes all members, when you had no default.conf yet, the Load part of the constructor would fail because it did not find the file (duh) and several members remained uninitialized, a bit later the IsModified was checked and the modified member was by accident true this resulted in the startup of CB to ask to save the defaul.conf, while actually nothing had happened to it. Maybe some of these uninitialized behaviour could have caused the crashes. Due to the failure of the loading (NotOk) the project manager had no valid pointer value for m_pWorkSpace

- continueing on the previous issue, when a project was then loaded, nothing happened to the workspace because of the no valid m_pWorkSpace pointer, and at shutdown of CB the same thing happened, nothing got saved in the default.workspace since the m_pWorkSpace  was 0.

- the workspace loaders :
  + one of them had a member for a version number which was totaly unused ->removed
  + they contained a title member which they only used at Open and could be "Get" but at save one had to specify the title as an argument --> title member has been removed as a member and is now an I/O argument to the Open method where the only client of those workspaceloeaders (cbWorkspace) will deal with it, cbWorkspace not itselves start's with it's title being "Default Workspace". So things are a bi more consistent.
   [SideNote : during debugging those workspace loaders would return intheir GetTitle method either their m_Title or in the case it was empty "Default workspace", but I saw oit ending up injust the first character 'D", and it was the first character because in once changed the code to "Xefault workspace" ;-) and then I had an X . cbWorkspace could also have an empty title when there was no workspace loader, but there's should always be a workspace loader, now also i nthis case the title will be the default ]

- the client of the workspace : the project manager and the app (main.cpp app.cpp projectmanager.cpp) : very little change in the project manager instead of having 3 times the same code, 2 of them fall back on the third method. And on the app level no need to specify the default argument, a call without specified arguments is sufficient (also here it was inconsistent : once called without specifying it once with)

Another thing I also want to change (did no do it yet) is moving the DEFAULT_CONF (== default.workspace) from globals.h to cbWorkSpace. it is used in the cbWorkSpace (obviously) and as default argument to LoadWorkSpace method of the projectmanager. It even can be exported i think in the dll. My view : it does not belong in the globals.h, it should be a public static member of cbWorkSpace --> cbWorkSpace::DefaultConf.

That's about it for my changes.

marfig:
Well, I did as you suggested and did a clean install on another folder, having previously removed default.workspace and default.conf. It works like a charm. I can no longer reproduce the error.  :)

I don't have much free time right now. But if after this, if you would still prefer a more detailed testing and some cut down version of my projects, let me know and I will provide them tonight (I'm at GMT).

killerbot:
well good to hear now everything works. I suspect your default.conf to maybe be the guilty party.
When you have time and you feel to further investigate you are always welcome to do so. Now we don't know yet what the "real" cause is. It is always better to know ;-)
But if you don't feel like it, well no problem, major point is thing is solved also know on your system :-)

Navigation

[0] Message Index

[*] Previous page