Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: mushakk on March 03, 2008, 09:10:17 pm

Title: Debug inside inl (inline files)
Post by: mushakk on March 03, 2008, 09:10:17 pm
Many people (like me) separates declaration from definition in all classes. For templates normally we use the .inl extensión.

Please permit debug inside .inl files.

Thanks for your work.
Title: Re: Debug inside inl (inline files)
Post by: DrewBoo on March 11, 2008, 11:47:49 pm
Many people (like me) separates declaration from definition in all classes. For templates normally we use the .inl extensión.

Please permit debug inside .inl files.

Thanks for your work.

I also have used .inl on some projects.

Are there any plans to allow the end user to outright specify what extensions are valid for certain file types and expose that list in the SDK?
Title: Re: Debug inside inl (inline files)
Post by: MortenMacFly on March 12, 2008, 08:38:35 pm
Mind providing a little sample project? I'm under the assumption this should be possible...
Title: Re: Debug inside inl (inline files)
Post by: DrewBoo on March 12, 2008, 08:49:54 pm
Mind providing a little sample project? I'm under the assumption this should be possible...

Morten, you're everywhere.   :lol:

.inl is synonymous for .h or .hpp for many people.  It's just another extension for a file that gets #included.

I've also worked on projects where ".C" and ".H" files were used (instead of lower-case).  I had to modify several core files on my local machine to hack that functionality in, which is why it may prove Useful Enough(TM) to have C::B let the end user modify which files extensions are considered C++ source, C++ headers, etc.
Title: Re: Debug inside inl (inline files)
Post by: MortenMacFly on March 13, 2008, 09:50:28 am
which is why it may prove Useful Enough(TM) to have C::B let the end user modify which files extensions are considered C++ source, C++ headers, etc.
Well... did you ever try righ-clicking on a project and then select "Project Tree" -> "Edit file types and categories"???
Title: Re: Debug inside inl (inline files)
Post by: DrewBoo on March 13, 2008, 04:13:07 pm
Well... did you ever try righ-clicking on a project and then select "Project Tree" -> "Edit file types and categories"???

I DID NOT.   :oops:
Title: Re: Debug inside inl (inline files)
Post by: MortenMacFly on March 13, 2008, 08:08:36 pm
I DID NOT.   :oops:
LOL... such things can happen. :P (BTW: You'll find this feature via the project menu, too.)
Anyways: Does it work for "inl" files??? It really should. I see no reason why it should not work if you add this extension to the "source files" category that way.
Title: Re: Debug inside inl (inline files)
Post by: DrewBoo on March 13, 2008, 08:36:00 pm
Anyways: Does it work for "inl" files??? It really should. I see no reason why it should not work if you add this extension to the "source files" category that way.

I tried a test on mushakk's behalf.

I defined an inline function in a .inl file, included it, and called it with a breakpoint.

I got the same results when adding "*.inl" to both Headers (what i think is the common practice) and Sources (what you suggested).

The debugger halted at the correct place, but did not open the file.  Double-clicking that function in the call stack window also did not open the file.
Title: Re: Debug inside inl (inline files)
Post by: DrewBoo on March 13, 2008, 08:40:18 pm
Anyways: Does it work for "inl" files??? It really should. I see no reason why it should not work if you add this extension to the "source files" category that way.


AH!  Here's the answer.

And this is why I didn't know about "Edit file types and categories"...I had already browsed through the codebase and swore I had seen hard-coded file extensions.   :D

Here's a peek at ./src/sdk/globals.cpp.  This function is called to make sure the debugger only opens source and header files.
Code
FileType FileTypeOf(const wxString& filename)
{
    wxString ext = filename.AfterLast(_T('.')).Lower();

    if (ext.IsSameAs(FileFilters::ASM_EXT) ||
        ext.IsSameAs(FileFilters::C_EXT) ||
        ext.IsSameAs(FileFilters::CC_EXT) ||
        ext.IsSameAs(FileFilters::CPP_EXT) ||
        ext.IsSameAs(FileFilters::CXX_EXT) ||
        ext.IsSameAs(FileFilters::S_EXT) ||
        ext.IsSameAs(FileFilters::SS_EXT) ||
        ext.IsSameAs(FileFilters::S62_EXT) ||
        ext.IsSameAs(FileFilters::D_EXT) ||
        ext.IsSameAs(FileFilters::F_EXT) ||
        ext.IsSameAs(FileFilters::F77_EXT) ||
        ext.IsSameAs(FileFilters::F90_EXT) ||
        ext.IsSameAs(FileFilters::F95_EXT) ||
        ext.IsSameAs(FileFilters::JAVA_EXT)
       )
        return ftSource;

    else if (ext.IsSameAs(FileFilters::H_EXT) ||
             ext.IsSameAs(FileFilters::HH_EXT) ||
             ext.IsSameAs(FileFilters::HPP_EXT) ||
             ext.IsSameAs(FileFilters::HXX_EXT)
            )
        return ftHeader;

// ...(etc.)


...and that code is being called from here in debuggergdb.cpp
Code
void DebuggerGDB::SyncEditor(const wxString& filename, int line, bool setMarker)
{
    if (setMarker)
        ClearActiveMarkFromAllEditors();
    FileType ft = FileTypeOf(filename);
    if (ft != ftSource && ft != ftHeader && ft != ftResource)
        return; // don't try to open unknown files

The solution may be to redefine FileTypeOf to use the custom list, but at the very least the debugger plug-in could be changed so that it doesn't return from that function unless the editor is absolutely incapable of opening the file (e.g. it's a binary)