Hi,

for me it is a little bit annoying if changing the names of entity names in the entity tree.

U select an entity, press F2 and a dialog appears where to change the name. After changing it and pressing Enter, the tree must be refreshed. That's, of course, necessary.

But why the whole tree lost its focus? Why is the index of the changed not stored and the focus set back to the changed element of the tree? So now after each change, and I've to change very many entries, I have to fetch for the mouse and select the entry by myself, and this hundreds of times.

That's really not nice. Is it so difficult to store e. g. the whole path to the changed entity before doing the change on the tree and then go to the element, show it and set the focus to it? As I think in .NET it is quite easy, isn't it?

Suggesting greetings

Reiner

Working fine over here, using May 1st, 2012 Designer build.

Also, if you have to rename a lot of entities, please check why you have to do that. We have a lot of features built-in for reverse engineering names during the reverse engineering process, so it might be easier to use those instead (e.g. remove '_', casing correction, abbreviations etc.).

I've to do it because of ORACLE!

In the DB ALL names are upper case and when importing into LLBLGen U get names with just the first character upper case. But I'd like to have element names in Camelcase.

And if you've about 120 tables with more than 130 constraints there is much more inside of LLBLGen to change.

So if U change the name at a leaf of the tree it is annoying if after pressing Enter or clicking on Ok and the rebuild of the tree is done, the focus is not on the tree but on the left and the tree is partitially collapsed.

Therefore I asked why not in the Click event of the OK button the new name/path for the leaf is build from the part before and the new name and when rebuild the tree went to the new leaf and call for the focus?

At the moment the hands have to leave the keyboard, go to the mouse, move the cursor to the possible parent element where the change leaf belongs to (sometimes difficult in the forrest of those many elements), open the tree until the changed element appears and set the focus to it.

All in all the most time now takes it to do this normally unnecessary 'work'.

Explaining greetings

Reiner

rblock wrote:

I've to do it because of ORACLE!

In the DB ALL names are upper case and when importing into LLBLGen U get names with just the first character upper case. But I'd like to have element names in Camelcase.

And if you've about 120 tables with more than 130 constraints there is much more inside of LLBLGen to change.

There's a setting for that. Please see the 'Element Name Construction' settings in project settings. I also think it's setup properly by default, so I don't see how you can end up with uppercase names in the entities...

Make sure 'Enforce Pascal casing always', and 'Make element name pascal casing' are checked, then re-create the entities.

So if U change the name at a leaf of the tree it is annoying if after pressing Enter or clicking on Ok and the rebuild of the tree is done, the focus is not on the tree but on the left and the tree is partitially collapsed.

where are you renaming things? I can't reproduce it when I rename an entity. When renaming a navigator, it's refreshed, because the subtree is rebuild.

But you shouldn't do this by hand, check the patterns and settings for automatically create the proper casing, underscores etc. for you.

Therefore I asked why not in the Click event of the OK button the new name/path for the leaf is build from the part before and the new name and when rebuild the tree went to the new leaf and call for the focus?

Because the tree is updated at most once a second.

Hi Frans,

Otis wrote:

Make sure 'Enforce Pascal casing always', and 'Make element name pascal casing' are checked, then re-create the entities.

I did it, not the entities in LLBL where uppercase. ORACLE stores all names in uppercase. I switched on this Pascal casing but what shall the LLBL do? It does not know the words therefore just the first character is uppercase and the rest lowercase.

Otis wrote:

where are you renaming things? I can't reproduce it when I rename an entity. When renaming a navigator, it's refreshed, because the subtree is rebuild.

Please take a look at the screenshot I added to my first message in this thread.

Otis wrote:

But you shouldn't do this by hand, check the patterns and settings for automatically create the proper casing, underscores etc. for you.

That is impossible for a software without a language specific dictionary when the source name is all upper- OR lowercase.

Otis wrote:

Because the tree is updated at most once a second.

When U right click on a leaf and change the name in the dialog that appears and press the OK button, just in this moment the tree is rebuild.

Over here I attached a small screenshot with a naming example, what happens during import with uppercase names and camelcase switch on.

Complementing greetings

Reiner

rblock wrote:

Hi Frans,

Otis wrote:

Make sure 'Enforce Pascal casing always', and 'Make element name pascal casing' are checked, then re-create the entities.

I did it, not the entities in LLBL where uppercase. ORACLE stores all names in uppercase. I switched on this Pascal casing but what shall the LLBL do? It does not know the words therefore just the first character is uppercase and the rest lowercase.

It checks for word breaks. If all names are uppercase, you likely have underscores in the names as well, like CUSTOMER_ID, or COMPANY_NAME. It will convert those to CustomerId and CompanyName. If there are no _ on wordbreaks, then indeed it doesn't know.

It's common practice on oracle to use underscores to make names more readable. If everything is uppercase and no underscores are used, things are unreadable if they get longer. But I don't know whether your system has this or not.

Otis wrote:

Because the tree is updated at most once a second.

When U right click on a leaf and change the name in the dialog that appears and press the OK button, just in this moment the tree is rebuild.

Over here I attached a small screenshot with a naming example, what happens during import with uppercase names and camelcase switch on.

Ok. I can reproduce it now. Btw, rename navigators below the entity, not below the relationship. It works OK, but the relationship is removed and re-added, so it's going to be collapsed afterwards. Just rename the navigators, which is easier.

It re-adds the nodes, (as they're re-sorted, a name change can cause that the names have to be resorted), and doesn't set focus back onto the node which was focused last. The main issue is that the old nodes which were 'selected' are now gone, new nodes (with the same, or different text) are re-added.

We'll see what we can do, but I can't promise anything...

Hi Frans,

first I've to appologize because I wanted to write Pascalcase but wrote Camelcase.

The Problem with ORACLE is that the max. length of names is 30 characters. And as U already can see on the sceenshots many of them are longer in order to make the DB itself a little bit more readabel I don't wanted to waste space for underscores.

And yes I already recognized that it is best to change the names below the Navigator as the screenshots show.

Hm, did I wrote that, after changing the name and clicking on OK or pressing Enter, in the Click event it is possible to examine the trees path like it was before changing the name and then fetch the changed value of the text box and rebuild the new path to the changed element. This can be given to the a place where it is possible to get it after finishing the refresh. At the moment it is not to evaluate where the focus is after pressing OK. But at some place of the code the thread must wait for the next action happen. Somewhere it must be before as F2 was pressed. There normally it should return to. When F2 is pressed some event handler has to be called and there the rebuild of the tree must be done or there can be added an event handler to fetch the automatically occuring refresh finished event. There e. g. the new focus can be handled.

The different text or complete path has to be forwarded from the button_ok_click event handler to a place where other event handlers can reach it.

Thinking greetings

Reiner

We fixed the problem with the nodes becoming deselected after rename. This is true for: fields, navigators, fields mapped onto related fields. If you rename a navigator below a relationship, it still gets collapsed, so rename the navigator right below the 'Navigators' node below the entity.

Fixed in next build (may 31st)

Hi Frans,

that's really great!

Thanks for the help of U I now already received so often!

Thankfull greetings

Reiner