Thanks!
From a certain point of view, you are right. But there is also the issue of lowering the requirements for potential contributors. I am thinking about the financial requirements. If you need: a desktop version, a plug-in license and an Apple computer to fully prepare and test modifications to the project, itās not that cheap. If we can lower these requirements a little, why not?
Linux is cheap at least
- imSplitter is back (thanks to license change - thank you Olivier!).
- Instead of removing MBS plugins, I added the āuseMBSā constant in āmodGlobalsā module. By default = False: compilation does not use MBS plugins. If useMBS=True: MBS plugins will be used as in the original source code (I hope, but let me know if Iām wrong!).
- Despite use the āNormalize Control Sizesā switch, there was still a few TextField with improper height, because of that I added dirty manual corrections (on Linux only).
My modifications are here: https://github.com/pjaskulski/argen
In summary: it works on my lovely and cheap Linux now, that was my goal, I am happy
Thank you, Bob and Tim, for creating this tool, and thank you Jay for opening the source code to the community.
Piotr
I have not used ARGEN yet but I am trying to understand what it does and how it works.
Doing that a thought about how ARgen/ActiveRecord currently organizes the table classes occurred to me.
If I understand it, It looks to me that the current organization in a database module:
DataBaseModule
Classes
Table1Class
Table2Class
does not make it as easy as it could be to work on a morphing database with fields being added ectā¦
That is because with the events one would either need to implement the events in those classes or use AddHandler somewhere, and sometimes even add more methods or do other modifications to those classesā¦ and that would make generating the class or DB changes and having to redo that stuff more of pain than it needs to beā¦
One could subclass the generated class and and implement the events and add new methods (or override existing ones) thereā¦
But now you either wind up with the new class having different name, or changing the generated class name, making it private and giving the original name to the subclassā¦ messy
But what if ARgen/ActiveRecord used this organization:
DataBaseModule
Classes
Table1Class (subclass of mTable1Class)
Table2Class (subclass of mTable2Class)
Modules
PrivateClassesModule
Classes
mTable1Class (Only this needs to be replaced)
mTable2Class (Only this needs to be replaced)
I think that way updating for additional fields would be about as painless as possible and while it would add a little overhead, I doubt it would matterā¦
So for those who have used ARgen a lot, I am I totally off base here or would it not be worth the work to do?
-karen