Hi

When I use the designer I notice some "suboptimalities". Many of these things are due to the usage and how I use of Firebird.

1. It is not possible to delete fields tab of the entity editor. Maybe a right click would solve a lot for me. Now I always need to find the field in the tree.

2. Why force me to select a converter when you require one and there is only one that is compatible? I use a massive amount of typeconverters. I made from all the enumerations in my application, decent enumerations that are supported by llblgenpro. This is the best feature ever... but unfortunatly I need to attach the converter all the time and it always gives me a list with only one possible converter. An easy choice... since leaving it empty is also not allowed, but why not let the designer figuere it out himself.

3. the Default sorting on "name" in the fields editor. All our databases work with prefixes that represent an alias for the table. for ex table = T_CUSTOMER, dbField = F_CUST_ID, property should be Id. F_CUST_NAME = Name. I know I can remove these prefixes automatically, but there are hundreds of those and "removing" them is not always good.
   So I manually rename them once. This is only 10 seconds of work if the default sorting would not be on "name".

In my databases I also spend time on placing the fields togheter. In the designer they are spread around. Maybe just keep the sorting in de fields designer on the metadata sequence?

Thanks

This is it for now.

Alexander

Alexander wrote:

Hi

When I use the designer I notice some "suboptimalities". Many of these things are due to the usage and how I use of Firebird.

1. It is not possible to delete fields tab of the entity editor. Maybe a right click would solve a lot for me. Now I always need to find the field in the tree.

I think you misworded some words in that sentence, as I don't know what you mean: do you mean: you can't remove fields from the fields tab? You can, select them, click Remove Selected.

1. Why force me to select a converter when you require one and there is only one that is compatible? I use a massive amount of typeconverters. I made from all the enumerations in my application, decent enumerations that are supported by llblgenpro. This is the best feature ever... but unfortunatly I need to attach the converter all the time and it always gives me a list with only one possible converter. An easy choice... since leaving it empty is also not allowed, but why not let the designer figuere it out himself.

Good point. We'll look into fixing that.

Another way to help you is to define a typeconversion definition (right-click project -> edit typeconversion definitions). These definitions are for 'auto-insert' type converters.

1. the Default sorting on "name" in the fields editor. All our databases work with prefixes that represent an alias for the table. for ex table = T_CUSTOMER, dbField = F_CUST_ID, property should be Id. F_CUST_NAME = Name. I know I can remove these prefixes automatically, but there are hundreds of those and "removing" them is not always good.
   So I manually rename them once. This is only 10 seconds of work if the default sorting would not be on "name".

We're almost done with this implementation of custom field ordering which will come in v3.1 You can set settings which will keep things in-order with the target table/view field order, and you can specify your own field order (or leave it as it is now)

Otis wrote:

Alexander wrote:

Hi

When I use the designer I notice some "suboptimalities". Many of these things are due to the usage and how I use of Firebird.

1. It is not possible to delete fields tab of the entity editor. Maybe a right click would solve a lot for me. Now I always need to find the field in the tree.

I think you misworded some words in that sentence, as I don't know what you mean: do you mean: you can't remove fields from the fields tab? You can, select them, click Remove Selected.

Hmm... you mean the big button in the bottom that clearly sais "Remove selected". Hmmm... yeh, I could use that one too. Why not.

2 and 3

Thanks

It's indeed perhaps a bit misleading, but we didn't implement the DEL key there. The reason was that if the focus switched to the project explorer somehow and you were looking at the fields tab, pressed del, the selected entity/entities were deleted instead, naturally. It lead to problems during usability studies so we implemented a button.