POIDE: Function browsing prob

[migf1]

Hi guys,

I don't know if I'm the only one experiencing this, but it seems POIDE's full/function browsing starts getting a bit confused after a while. It either looses source files' +/- function (un)folding symbol in the tree, or when it unfolds them (or just some of them) it leaves some functions out of its listing. Sometimes it helps to "Update all depedencies" under the "Project" menu, but it starts again after a little while.

My current project consists of 6 source files, 9 header files (res included) and a resource file. I'm using Pelles C 3.0.4, on WinXP Professional SP1.
Perhaps I should also note, that I'm working on this project on two different PCs. When I want to transfer my work from one PC to the other, I copy the whole project folder to a PenDrive, from where I copy it to the other PC... and vice versa. One of the PCs is running Windows 98SE (fully patched) and the other WinXP Proff SP1.

Is this a known prob or am I doing something I'm not supposed to?

Thanks in advance...

[Pelle]

There are known problems with POBR.DLL - the browse information manager. I'm not sure they explain all your problems.

Mainly to speed up things, the program only scan source files - never #include files. This means it will not see some typdef's and macros that might change the syntax from "standard C" to something else ("Windows C"). Since the parsing needs to be fairly low-level to find all browse types, this is a problem.

I will do some research, and let the compiler generate browse information instead. This should give more "exact" information. This will, on the other hand, generate several new problems. For example, I want some of the browse information ("functions") to be available early for a project, before it's even built. There are other problems too.

Pelle

[migf1]

Thanks for your rapid answer Pelle!

It's good to know you are aware of the prob and that you have already put it in your to-do list (if I got it right)!

Pelles C is already a stunning package, for which I -for one- am greatful!

Best regards...

[Pelle]

It's good to know you are aware of the prob and that you have already put it in your to-do list (if I got it right)!

Yes, I'm on it. What I meant was that I have tried a few different solutions in the past - none of them completely successful. I can either spend the next xxx versions trying to patch up the current solution, or find another solution with probably new/different problems. Not sure what is best at the moment...

Pelles C is already a stunning package, for which I -for one- am greatful!

OK, thanks! :-)

Pelle

[migf1]

I wouldn't know how vital it is for PellesC's current code, or how easily can be done (or not) but perhaps a separate, dedicated module/function just for function-browsing (the tree) could be a possibly cleaner solution. I mean, disengaging it from other "irrelative" browsing stuff (e.g typedefs, struct members, etc).

But as I said, above, you know better (and I surely trust you!).

Btw, I have to state that in my time I used many C programming environments on several platforms (VMS, BSD Unix, Atari ST's GEM/AES, Macintosh's Finder and DOS/Windows). I find Pelles C the most compatible to my taste, both aesthetically and functionality-wise (I haven't tried VS though, for which I hear only good things).
This is not just a compliment, it's the plain truth! I haven't programmed for more than 10 years and PellesC (which I recently discovered accidentally) was the main reason for trying to remember the programming skills I used to have once upon a time :-)
Now most of my spare time (which unfortunately isn't too much) goes to learning Windows Programming using Pelles C!
(surprisingly, there are too many similarities in programming the now ancient GEM/AES and Windows!)

[l1ng0]

This is perhaps a little repetetive, but I also notice that the function list in the project window doesn't work for me, or rather, it works very randomly.  For some source files I can click the plus to expand the file and show the functions, but for most I click the plus and all that happens is the plus disappears.  Other times, only some functions are listed.
This is a shame, as it is a useful function when it works.

Is is just my coding style? Some of my older programs use K&R style, but I now tend to use mostly the following style, which is pretty standard.

return_type function(type arg, type arg)
{
 block;
 if( test )
 {
  block;
 }
}

Any ideas?

Cheers
 - Luke

[Pelle]

Is is just my coding style? Some of my older programs use K&R style, but I now tend to use mostly the following style, which is pretty standard.

I don't think the coding style matter that much - the problems I have seen are usually because:
a) typedef typenames are used (rather than 'long', 'float' etc.) - they can sometimes mess up things...
b) macros are used to "simplify" the syntax, thus hiding important keywords.

I have attached a copy of pobr.dll that is supposed to be in the next release (v4.00). I have found one bug regarding preprocessor conditionals (#if, #ifdef ...), and made a few other changes. The interface should be the same, so the file should work with v3.00 too. Can you please try with the attached version - to see if there are any improvements? ( Remember to make a backup-copy of your existing pobr.dll file! )

If not, I like to see one or more of the "problematic" files - maybe you can post or mail me the files?

Pelle

[l1ng0]

Well, it still works the same way with the new .dll, but thanks very much for posting it.
However, after reading your post I had another look at the code and I have found the culprit (or 1 of them

In order to remove a bit of messiness and provide some portability, I am using the following macro for some of my functions.
Sure enough, when I remove the macro, or replace it with the original text, the browser seems to work.

#define   DLLEXPORT __declspec(dllexport)

ret DLLEXPORT fn(...)
{
}

The above seems to cause the problems.

So, it is at least fixed in this way, although it is a pity not to be able to use this macro. I hope this helps you.

Cheers,
 - Luke

[Pelle]

OK - thanks for the info.

Well, this is a never ending story. I recently looked at using the compiler to build browse information (rather than a separare tool; pobr). The compiler will known exactly (of course) what is what in a program, but there are problems with this approach too:

1) I only want to emit type information for types that are actually *used* by the program (at least for a Windows program, the compiler will see many, many, types of which only a few will be used).

2) When I know the type is being used, it's store in an internal format. To get back to "human readable form" of especially "typedef" types, means adding additional information to every type - also the unused ones. This means allocating much more memory than today, which might be a problem on laptops, or other computers with possibly limited memory.

3) Using the compiler to scan source files for functions, when loading a project, will be slow - and require a "build" before functions are visible in the project tree is unacceptable too.

...and reading through all #include files, and process macros, in the browse info manager (pobr) will make it slow too - and more or less turn it into "another compiler". At least from a mantainance point-of-view pretty unacceptable...

So far I havn't found a solution that works well for all cases I want to support...

Pelle

[Pelle]

Luke,

Same problem - new try. Based on your description, I modified the browse info builder DLL again. Maybe this works better?!

Pelle

[l1ng0]

Well! That does seem to fix the problem with the DLLEXPORT define, but I still managed to break it!  Here below is what confused the poor thing

Code: [Select]


BOOL DLLEXPORT WINAPI DLLPROC(HINSTANCE hDLLInst, DWORD fdwReason, LPVOID lpvReserved)
{
    switch (fdwReason)
    {
        case DLL_PROCESS_ATTACH:
ghInst = hDLLInst;
            break;
        case DLL_PROCESS_DETACH:
ghInst = NULL;
       break;
default:
            break;
    }
    return TRUE;
}

Now, I was using DLLEXPORT as before, but also DLLPROC is another #define, used because I was comparing lccwin32 & pelles for something I now forget, and PellesC used DllMain (I think) and lcc used LibMain.  The combination of the two defines, and this func. being the first func in the file, meant that none of the functions showed up in the browser.
As soon as I cut this function out, ALL the other functions showed up fine.
So, you're half-way there.

Keep up the good work.
Cheers,
 - Luke

[Pelle]

Thanks, I will look at it.

Pelle

[Pelle]

Okay... maybe this then...?  :roll:

Pelle