Is there a current way, or are there plans in the future to be able to control the scope (public, private, ...) of the generated properties on the entity objects from the tool? I see that you can rename the property, but I'm looking for a way to limit access to the property. Similar functionality would also be usefull on the properties for relations.

-fyi, Im using the adapter template.

Thanks CT

ctadlock wrote:

Is there a current way, or are there plans in the future to be able to control the scope (public, private, ...) of the generated properties on the entity objects from the tool? I see that you can rename the property, but I'm looking for a way to limit access to the property. Similar functionality would also be usefull on the properties for relations.

-fyi, Im using the adapter template.

In Q1 we hope to deliver this functionality yes, where you can set field properties in the designer which are used by the code generator, like accessor types (only the cross-language ones) and hiding of fields, adding new fields etc.

After using this tool for a while with a large database, 150+ tables, the ability to hide relationships is becomming very important. A simple checkbox in the designer is all I'd need for now.

Thanks CT

ctadlock wrote:

After using this tool for a while with a large database, 150+ tables, the ability to hide relationships is becomming very important. A simple checkbox in the designer is all I'd need for now.

Thanks CT

I know, that's why development of this and other features starts monday

Thank You; You have the best customer support of any product Ive ever worked with.

CT

Any status on this....?

Thanks CT

ctadlock wrote:

Any status on this....?

Thanks CT

In progress.

I hope to finish the current development cycle late April. I first do as much class refactoring as possible, as that's the main issue for doing all these updates at once: it will break project formats. (save in the new one -> no load in the old one). This will make it possible to delay some smaller gui enhancements to a slighter later date without a big problem.

Firebird driver now works 100%, all descriptions/extended properties/comments are now read from sqlserver/oracle/firebird as well into tables/fields/views/procs/parameters and entities/proccalls/typedviews/typedlists. A lot of work has been done to make the gui more responsive in large projects. Now in a large project when you rename an entity, delete an entity, add an entity, they changes are propagated instantly.

The database drivers now contain the connection parameter control as well, which opens the way for opening their sourcecode in the next SDK update, plus eventually 3rd party developers who want to develop a driver for a typical database. Although I'm participating in the Pervasive .NET provider beta, I've postponed this driver till the driver development period, in May.

Furthermore, thanks to the great guys of Janusys, a lot of controls will be replaced by their gridEX so more things will be editable more easily.

Frans,

Does the property accessor changing possibility from the designer is still in your plan?

In another thread (before found this one) i asked, how to change the property and method accessor type via code, or is it possible to create a custom template to do that?

Thank you in advance

Gabor

It's on the todo for considering, htere are no concrete plans when to implement it. I'll answer your question more in depth in the other thread.