stronger seperation / better error reporting user libraries

[blueznl]

seeing all the trouble being caused by userlibs, and realizing that they are still essential, i'd like to suggest the following:

(actually, this is more to make life easier for everybody, to spot the cause of any troubles)

1. make sure all userlibs, including their help files etc. reside together in one directory, with a sub directory per library

this way it's more clear what belongs where, (with eventual subfolders below) so its easier to remove / add to any of them

2. add a field to a userlibrary (extra file perhaps that sits in that subdir?) that indicates what version of pb the userlib is for, userlibs without that file or for an older version can be reported with a warning on compilation time

3. report on an error what caused the eror, ie. report if it was a userlib or not

i think this would save a lot of confusion, time and annoying bug reports

[Dare2]

Good ideas.

[NoahPhense]

with a sub directory per library...

Oh I like that.. everything in it's place.. sounds good. That way the
when PB loads.. it doesn't just search /UserLibraries/ but all subs..

Not sure if you mentioned it, but have /Residents/ do the same..

- np

[blueb]

bluenzl,

I agree. To get 3.91 to work I had to rip out ALL of my installed userlibs. I've re-inserted only 2 or 3 because of errors.

Overall, I'm not sure what to do with userlibs that I have not created. There's so much good code provided by some very good coders, that I do want to install these userlibs, but I really don't want problems running PureBasic. Hmm..... Catch 22

blueb

[NoahPhense]

bluenzl,

I agree. To get 3.91 to work I had to rip out ALL of my installed userlibs. I've re-inserted only 2 or 3 because of errors.

Overall, I'm not sure what to do with userlibs that I have not created. There's so much good code provided by some very good coders, that I do want to install these userlibs, but I really don't want problems running PureBasic. Hmm..... Catch 22

blueb

I really don't have any issues with UserLibs. Except for poorly designed
ones. And well, they make it quickly to the trash can. I haven't had any
real issues with 3.91.. I can only think of 2 right now, but there were
fixes already out before I even asked about the issues.

One being the OnError lib.. boom, Fred put out a new one.
http://www.purebasic.com/beta/

I think what happens sometimes, is that people junk up their primary
folders, /Residents/ /UserLibraries/, some of the advanced developers
even go as far as to replace some of the standard Libs that come with
PB.

What I like about the above mentioned, is more structure, nothing
complicated, maybe something like this:

/Residents/ <-- would contain all shipped .res files
/Residents/myRes/ <-- whatever sub folders I add

PB should go sub searching, and load them up..

As well:
/Residents/NOUSE/ <-- PB would recognize this folder or whatever Fred
decides to label it -- as a folder to NOT load .res from.. that way we could
just quickly move our junk around with ease.. ?

--

Same goes for the /UserLibraries/myNewLib/ .. <-- PB would do sub-dir
inheritance..
/UserLibraries/NOUSE/ <-- same as above -- do not load anything in here

--

just thoughts..

- np

[naw]

I've had probs a couple of times with clashing commands in UserLibs. It would be nice if PB had a dialog screen that allowed you to disable troublesome Libs. Or even told you which UserLibs had a clashing command name...

[NoahPhense]

I've had probs a couple of times with clashing commands in UserLibs. It would be nice if PB had a dialog screen that allowed you to disable troublesome Libs. Or even told you which UserLibs had a clashing command name...

Maybe an IDE Tool is in order. I'm certain with the OnError stuff, we could
easily catch the conflicts. Matching them to a lib might be interesting.

Just a side note. If you're using 'many' UserLibs in your app, then
you're looking for trouble anyway. I only mean that in the sense that
"hopefully", the people creating the libs you are using, will support them
as long as you are supporting your application. Because as PB moves
forward, sometimes these libs don't like the new PB..

That is why I take careful pride in developing my libs with API. And have
made a pact with myself, that I would never release a lib that I would
not continue on with.. and even in a worst case scenario, I would just
shoot out the source for my lib, if I didn't want to tool with it anymore.

- np

[oldefoxx]

The big problem with UserLibs is the conflicting definitions. These will
prevent the compiler from loading as it should. If you have multiple definitions of the same variable that do not conflict with each other, this is not a problem.

But what if the compiler, instead of complaining and stopping, just replaced the existing definition with the current one? That way, instead of hanging up, it would continue on loading and be able to do its job. Sure, the current definition may not be the right one, but that is a separate issue that could be sorted out later. For instance, you could include a specific reference in your source code to a RES file with the "right" definitions, and again, the compiler would overwrite existing ones with the "correct" one as it compiles your program. Those you don't address could remain as they ared.

To facilitate the effort to erradicate or correct any "wrong" definitions, you could have the option that a RES log be generated that shows the order in which the RES files are searched, and reports only when an existing definition is replaced with one that does not agree with it. That way you would at least know that the previous definition had to been in a previous file or found previously in this file. You could then write a program to process the log file and nail any prefious reference to the file or section where it occurred.

This would eliminate the current problem with conflicting definitions effecting the compiler's ability to load, and minimize the impact found in some libraries being poorly structured, or different releases of the Windows API's causing unexpected conflicts.