Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Codeblocks crashing when closing project options dialog

<< < (2/4) > >>

MortenMacFly:

--- Quote from: Biplab on March 05, 2007, 01:04:33 pm ---I think we should put a MessageBox throwing some *Warning* message before returning 0 in GetCompiler() or at least throw some messages in the Debug-Log. User would come to know about this problem then.

--- End quote ---
I'm not sure about that. This may confuse people who disabled the compiler plugin on purpose (imagine they are using C::B for Python development or similar). Because they would see this message over and over again (just count the number of GetCompiler() calls accross C::B). An AnnoyingDialog wouldn't be of much help I suppose.


--- Quote from: Biplab on March 05, 2007, 01:04:33 pm ---Alternatively it can be set to return Default Compiler. :)

--- End quote ---
This wouldn't work entirely if the compiler plugin is disabled because in that case there is no default compiler.

In the end I believe mainly we should ensure proper NULL checking and react appropriate in the calling method, thus not allow GetCompiler() to report "misuse". Why? Because GetCompiler() can't really know whether it *is* a misuse or not. The call can be fully correct and not an error.

With regards, Morten.

MortenMacFly:
Ok... I've had another look into. I think to fix this issue we should simple edit lines 348- ~368 in projectfile.cpp as following:

--- Code: ---            else
            {
                if (pf->GetParentProject()->GetExtendedObjectNamesGeneration())
                {
                    object_file_native = objOut + sep + fname.GetFullPath();
                    object_file_flat_native = objOut + sep + fname.GetFullName();

                    if (compiler)
                    {
                        object_file_native += _T('.') + compiler->GetSwitches().objectExtension;
                        object_file_flat_native += _T('.') + compiler->GetSwitches().objectExtension;
                    }
                }
                else
                {
                    if (compiler)
                        fname.SetExt(compiler->GetSwitches().objectExtension);
                    object_file_native = objOut + sep + fname.GetFullPath();
                    object_file_flat_native = objOut + sep + fname.GetFullName();
                }
            }

--- End code ---
And that's it. This will fix the crash. Unfortunately I don't have access to SVN ATM - maybe another dev could... after approval?!
With regards, Morten.

Biplab:
That's a nice fix. :D


--- Quote from: MortenMacFly on March 05, 2007, 01:34:42 pm ---This will fix the crash. Unfortunately I don't have access to SVN ATM - maybe another dev could... after approval?!

--- End quote ---

I can put it, if you wish. ;)

Regards,

Biplab

MortenMacFly:

--- Quote from: Biplab on March 05, 2007, 01:38:59 pm ---I can put it, if you wish. ;)

--- End quote ---
I didn't verify completely but I believe things are better with this "patch" applied... so please go on! ;-)

Biplab:
One more clarification: It would avoid the crash. But if the object extension is not set, will it compile? I think it can create problem. IMHO, user should be informed that C::B can't get compiler to avoid further problem. :)

Or, let's fix the crash first and we'll think about the other part later.

Waiting for your reply before I apply the patch.

Regards,

Biplab

Navigation

[0] Message Index

[#] Next page

[*] Previous page