I think you mentioned that there are some items that are not needed any more. Perhaps field factories and they are just there for backward compatiblity?

Are these things not included in the default task queue? In other words, on a new project I want to generate the least amount of code/classes needed? Is that what you get out of the box?

BOb

These tasks are disabled, you see them as greyed out. If you want to enable them, it's easy as you can just check the checkbox on them. I've added them as disabled, to make it easier for people who want to have these tasks enabled and in this case they don't have to worry they're at the right spot (e.g. after the directory creator task )

Otis wrote:

These tasks are disabled, you see them as greyed out. If you want to enable them, it's easy as you can just check the checkbox on them. I've added them as disabled, to make it easier for people who want to have these tasks enabled and in this case they don't have to worry they're at the right spot (e.g. after the directory creator task )

So what does this mean from the docs?

_ ResultsetFields classes don't have to contain the DefineField(enum... ) overloads for each entity. They're still provided with backwards compatibility templates, though in new projects it's recommended you move the backwards compatibility templates down in the generator config screen so you won't get these overloads in the code. _

Is that done on the "Template Bindings" page? I need to move the "SD.Templatebindings.SharedTemplates.BackwardsCompatibility.NET20" to the bottom of this list?

Also, I have done this, and when I return it is in the same location?

Thanks, BOb

pilotboba wrote:

Otis wrote:

These tasks are disabled, you see them as greyed out. If you want to enable them, it's easy as you can just check the checkbox on them. I've added them as disabled, to make it easier for people who want to have these tasks enabled and in this case they don't have to worry they're at the right spot (e.g. after the directory creator task )

So what does this mean from the docs?

_ ResultsetFields classes don't have to contain the DefineField(enum... ) overloads for each entity. They're still provided with backwards compatibility templates, though in new projects it's recommended you move the backwards compatibility templates down in the generator config screen so you won't get these overloads in the code. _

Is that done on the "Template Bindings" page? I need to move the "SD.Templatebindings.SharedTemplates.BackwardsCompatibility.NET20" to the bottom of this list?

That's a template situation indeed. The task is the same: generate ResultsetFields, but you can select which template to use for that task using the precendence list of the templatebindings: if you keep the backwards compatibility template bindings at the top, they overrule the other template bindings of the same templateIDs. Moving it to the bottom makes that the backwardscompatibility templates aren't used.

Also, I have done this, and when I return it is in the same location?

Thanks, BOb

Same location as in: the same location you moved it to or the same location it was before you moved it?

Otis wrote:

Same location as in: the same location you moved it to or the same location it was before you moved it?

Same location before I moved it. It didn't remember where I moved it.

It seems that this is saved in the .preset file... but, just moving down the template binding didn't show the preset as dirty and needing to be saved. I found this out because I moved it down AND edited the runqueue in my preset down, which prompted me to save it. Now when I come in the template binding order had been saved.

BOb

pilotboba wrote:

Otis wrote:

Same location as in: the same location you moved it to or the same location it was before you moved it?

Same location before I moved it. It didn't remember where I moved it.

It seems that this is saved in the .preset file...

No it's saved in the project if the generation is actually started. If not, it's not saved. Presets are just the runqueue.

but, just moving down the template binding didn't show the preset as dirty and needing to be saved. I found this out because I moved it down AND edited the runqueue in my preset down, which prompted me to save it. Now when I come in the template binding order had been saved.

The project should be marked changed when you move the template bindings, AND start the generator.

Otis wrote:

The project should be marked changed when you move the template bindings, AND start the generator.

Ok, I tested this again. It is not saving the binding precedence at all. I have started the generator.

Ok. I'll check it out. It should save the order of the templatebindings.

I can't reproduce it. I moved the backwards compatibility templates to the bottom of the list, then generated code. I then pressed F7 again and they're in the same order: backwards comp.. is at the bottom.

Be sure to SAVE the project to keep the settings you used when generating code. If you don't save the project afterwards, the order is lost and you'll get the default back next time you press F7 after you re-loaded the project.

Otis wrote:

Be sure to SAVE the project to keep the settings you used when generating code. If you don't save the project afterwards, the order is lost and you'll get the default back next time you press F7 after you re-loaded the project.

The project is not being marked as dirty so I can't save it. Here are the steps I follow:

Steps: Open LLBLGenPro Open Project from Recent Projects Choose Generate Form Project Menu Click on Template Bindings Tab Move Template Binding Down Click Start Generator Log Viewer Displays... Click on Close Button

Observed At this point I can not save the project... Only the Save As... menu item is enabled. If I Generate again at this point, the bindins are in the position from the last generate.

Steps: Close LLBLGen (not prompted to save) Repeat steps above, notice bindings have returned to original position

Observed: If I go in and make another change to the project, in order to be able to save it, the template bindings order is saved. If I "only" Open / Change Binding Order / Generate / Close the project is never dirty or saveable.

Expected: Changing the binding order should dirty the project and force a save prompt when closing or allow it to be saved. The expected behavior happens if I change the Template set for example.

BOb

Reproduced. Changing the order alone doesn't make the project dirty. Will fix.

Heh, it only compared the size of the collections . Fixed in next build.