First I would like to thank BKeeney software for coming up with AR. It really makes the day for database projects.
I recently purchased ARgen and am trying to learn how to use it before taking it on in a project I am about to start. To this effective I will be seeking help through this forum on ARgen related topics. This is because the user guide provided with Argen does not get to bone but I must mention that Argen itself is a lovely piece of work that I am not willing to let go. Thanks to Bob Keeney.
To start with I created a simple Contact Manager App to help me get to speed with AR. I will start with the following issue:-
ARgen has generated UI code for each of my tables registered. In my Contact Manager App, I have a table called CONTACTS with fields like ContactID, FirstName, LastName, CompanyName, etc. Argen generated for me a WebPage to search, scroll thru, select, edit and delete each record. Very Lovely. The problem is that after generating the code, I have decided to skip a columns from showing the ListBox. I saw that the rows are build using the BuildRow() method. I simply commented out the particular fields to be omitted in the ListBox and indeed it was omitted during run time.
The issue is that the corresponding column HEADER did not get omitted with this change and now my HEADER column in the ListBox does not correspond with the data displayed in the rows. the HEADER in the ListBox is still showing the commented out colums !! . Kindly help how I can omit the corresponding colum HEADER without having to run ARgen again.
The problem with running ARgen is that it generates a fresh project and overwrites all other code that was generated in the initial run. Is it possible to run ARgen and just have it make some simple additions/changes without affecting the rest of the code for other tables?
Please help I am new to ARgen but would like to learn very quickly how to use it.
Unfortunately, ARGen is not currently able to make incremental changes. It sounds like the small change you’d like to make is very simple, you wouldn’t need to run a small interface change through ARGen. Change the number of columns on the Listbox, remove the heading from the Listbox.Open event, and remove the corresponding arsRow.Append line.
Thanks Tim for your response. Tough as the fact stands that ARgen is currently not able to make any incremental changes, what would be the best practice when using ARGen for a project whose database schema is likely to change over time?
ARGen wasn’t designed, at all, to do incremental changes. It’s a convenient way to get started and to do work in chunks. I almost never use the project it generates but instead copy/paste the relevant classes/UI over into my project.
So bring over the ActiveRecord classes and generated UI only as you need them into your project (don’t forget to Register the table/class!). Since ARGen puts in a lot of #pragma error statements for everything that you need to finish it’s just not worth doing it all at once - especially on large projects… You generally go in phases anyway so first get the connection established, then Users table/UI for login. Then customer list and add/edit and so on.
If you’re just adding/removing a single field it’s easy enough to remove it from the AR class in your project. Compile and see where it fails. If someone has added a field you didn’t know about then ActiveRecord will throw an exception while debugging (final executable it doesn’t care) telling you what field is missing.
Where ActiveRecord doesn’t help is if someone deletes a field. Currently there’s no way of checking for that in the schema check. You can add as many properties on your own into the classes to unless we were to add an attribute or something like that we’d never know if a property was assigned to a database column or something you added on your own.
So to get back to your original problem you’ll have to note where ARGen sets up the listbox column count and the column headers. Also note that there is sorting code that goes on so be aware of that too. Listboxes aren’t complicated but they do have a lot of moving pieces. For UI, in general, we do some guesses and set it up as best we can but ultimately it’s up to you do the spit and polish of the UI - there’s just too many permutations that we’d never be able to handle automatically.