PureBasic Forums - English

Removed due to black hole.

collectordave wrote:Just one other point was noted when creating projects in that a file included in the project was not copied to the project directory so when editing my project I was editing the original file. Just a little heartache later, I now copy the files manually to my project.

i think it's meant to be that way as it allows you to have common includes used across many projects. And then if you ever find a bug or decide to enhance it you only need to update the one include file and all the projects that use it instantly benefit. If you need a specific version of an include file for a particular project then yes modify and use a copy instead. The best of both worlds!

collectordave wrote:Just one other point was noted when creating projects in that a file included in the project was not copied to the project directory so when editing my project I was editing the original file. Just a little heartache later, I now copy the files manually to my project.

Definitely -1

This is one of the things that I used to hate most about programming in VB. You create a common function module and import it into a bunch of projects that need it - then when it needs updating you have to update every project which refers to it manually. You can never be certain that everything is using the current version without checking manually. It's a version control nightmare! It used to drive me round the twist... VBA used to be even worse because the imported modules weren't stored in a human readable form except inside the IDE so command line tools like diff and patch were useless... </soapbox>

I am sort of with collectordave on this one. I have projects going back 14 years, many that use the same modules. The differences are in the variables, types, addressing, pb syntax, commands replaced or removed entirely and other things that would work on one program but kill dead an older project done in a very much older version of pb.

So common modules are no longer really that common any more unfortunately. I found that out the hard way as well.

Removed due to black hole.

The problems you describe are easily handled with version control software like Fossil or git.
Common lib's are the foundation of programming. When you have a conflict between 2 app's calling the same procedure, then rename the modified procedure or expand it to handle both app's.

Removed due to black hole.

Removed due to black hole.

My best analogy is you can hold up a few sheets of paper with a thumb tack. But a hundred sheets of paper require a professional fastener or a new paradigm like a shelf.
The sooner you adopt version control the better.

Removed due to black hole.

Your initial complaint was spurred on by your failure to implement version control. You assumed PB would do it. Unfortunately, it does not.

Therefore, you have already demonstrated that you need to implement version control yourself. You cannot rely on the IDE doing it. (BTW, do not hold your breath for this feature!) The system does not have to be a complicated system suitable for a team of coders. It just needs to be a way you can personally manage to avoid the situation you have already experienced. The other guys have given several examples that work for them.

Personally, I keep all of my code snips, modules and libraries cataloged in my C:\PB\Samples folder, with subfolders for each different topic (such as Strings, Math, Games, etc, and subfolders in those). My projects are in subfolders of my C:\PB\Projects folder. When I modify a module for a specific project, if those mods are project-specific, and not likely to apply to other projects, I copy the file to my project folder. Otherwise, they stay put. If the mods might break another program, I rename it, just as Demevic described. It's a super simple system, and can work for any level of hobbyist coder.

Removed due to black hole.

You are splitting hairs. Calling it a complaint was not a complaint on my part. No worries.

We address the issues we can. Any time you have a big list, it is unlikely for all of us to address the whole list, and as a result, often, items get overlooked. You are more likely to get responses you appreciate by creating several separate topics with specific topics, rather than lumping them all together in a very generic Subject that does almost nothing to describe the actual content.

If you want a native grid gadget, look for MicroGrid by RichardL, MyGrid by Said, SuperGrid by einander, or tGrid by Inner. I think there is also CS-Grid2-3.pb. You might also consider translating BabyGrid from Pelles C to PB. I agree, there are quite a few in various states, but I have merely saved a few, "just in case," without actually needing one.