Hi,

I already do change the settings. I alread do tried it many times but it does not work.

As U can see at the screenshots, the new found tables will not appear after finishing the synch.

I really do not have any idea what to do now!

Why the changes are not integrated?

EDIT1: The LLBL version is the current one from May, 1st.

Sighing greetings

Reiner

Just for the second screenshot.

Just for a third screenshot.

I started LLBL now as .NET 4.0 Any CPU version and got the errors shown in the screenshots.

A 4th screenshot (the ODBC Administrator)

A 5th screenshot (the ODBC Administrator)

Hi Reiner,

Ok, so you are using LLBLGen v3.5. For the error you get on the LLBLGen .Net4 runner, that's for the type of machine you have and the ODP.Net assemblies (x86 vs. x64). See this: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=20258&StartAtMessage=0&#114236

Now, about your first post, please see the Application Output panel at the bottom of the designer and tell us what it says. It should be info there that explains what happened.

About the user you are using to connect to the DB in LLBLGen, does it have dba granted?

Besides, we don't use ODBC, but the ADO.NET provider through the provider factory.

Hi David and Frans,

o.k. I made additional screenshots today. Over here is the Application Output.

and here the Result message

and last this is another Wizzard message.

I again selected all tables that are displayed with the toggle button. Then I just go on because U can't do any more. And yes, the user has all rights on the DB because I already created the DB schema with it. This many times because I'd to delete and create it often until it was ready designed.

O.k. I found the error by myself.

As U can see I just selected the tables itself but not the node Tables!

I did it because Oracle has many system tables like SYS_IOT_OVER_78062 etc.

Now I selected Tables and deselected the system tables by using the toggle button.

The result is shown in the attached screenshot.

But what to do that LLBL does not touch my already changed new Entity names? Because I camel cased the names and the import/refresh made them all lower case except the first char?

Relieved greetings

Reiner

IMHO this is a bug of LLBL because the node Tables should just be selected, in a two state case, if all child nodes are selected. Therefore U should use three state check boxes where one state is if just some of the child elements are selected.

Just my five cent...

I deleted the attachments, please zip ALL of them into 1 zip file and add that, thanks. Makes it easier for us to look at.

We'll look at your descriptions of the various problems you ran into and see whether we have some improving to do

@Frans: Done!

Attached ZIP to my last message.

Thanks! We'll look into it.

rblock wrote:

O.k. I found the error by myself.

As U can see I just selected the tables itself but not the node Tables!

I did it because Oracle has many system tables like SYS_IOT_OVER_78062 etc.

Now I selected Tables and deselected the system tables by using the toggle button.

The result is shown in the attached screenshot.

Hi Reiner. I can't reproduce this. I did: 1. Create a new project against the HR oracle schema, which is shipped with the OracleEX installer. 2. When selecting tables, I just selected two of them, when you select one, the Tables node is automatically selected as well. 3. Finish the wizard, and I see those two tables in Catalog Explorer. 4. Just to make sure, I refreshed the catalog, then selected two more tables. Those two were added to Catalog Explorer as well.

Maybe your steps to reproduce it are different. Please give us detailed steps to reproduce this. If possible, attach your .llblgenproj file and some DB DDL script. You can do this in the HelpDesk forum, which is private.

rblock wrote:

But what to do that LLBL does not touch my already changed new Entity names? Because I camel cased the names and the import/refresh made them all lower case except the first char?

We also need steps to reproduce this. This is how rename works:

1. Let's assume you have a ORDERDETAILS Table and you mapped to the entity Orderdetails.
2. You renamed the entity to OrderDetail.
3. At this point if you refresh the catalog, nothing will happen to your new name. So the entity is still named OrderDetail.
4. If you change the table name (say ORDERDETAIL) and then refresh the catalog, then the following settings are important:

Documentation wrote:

Sync mapped element names after refresh When set to true, LLBLGen Pro will rename any entity, navigator, typed view, entity field and typed view field if the name of the element they're mapped on has changed, for example a table field was renamed. Setting this option to true can break your own code, so use this option with care. When Sync renamed mapped element names after refresh is set to false, only non-manually changed element names are synced, otherwise all element names are synced. The value Default means the value in the preferences is used.

Documentation wrote:

Sync renamed mapped element names after refresh When set to true (default: false), LLBLGen Pro will sync manually renamed elements after a refresh if Sync mapped element names after refresh is set to true and the name of the element they're mapped on has changed. If Sync mapped element names after refresh is set to false, this setting is ignored. Multiple entities mapped onto the same target will all be resynced in case of a target name change, so use this setting with care. The value Default means the value in the preferences is used.

If they are set to default, they take the value from the LLBLGenPro Preferences. If you set both to false, your custom entity name shouldn't be changed.

We wish you wouldn't run into this, I feel it's a oversight doing the refresh or understanding the project settings. Or maybe it's something we must fix on the Designer, in such case we need steps to identify the issue.

Hi David,

no, I am sorry, but if U mark some tables in the table tree and then press the "Toggle checkbox of selected nodes", the schema node is selected and the tables itself but not the Tables node between them.

U can see it in the attached screenshot here.

BTW, something happend to the entity editor. If now first the type converter of the last row is selected the column does not adjust itself. Only if U change the type converter of the rows next to last or above. That was not in v3.1 I think.

Hinting greetings

Reiner

When I try it, only the selected nodes get their checkboxes toggle, when you press the toggle button. None of the upper level nodes get affected.

What am I missing?

rblock wrote:

Hi David,

no, I am sorry, but if U mark some tables in the table tree and then press the "Toggle checkbox of selected nodes", the schema node is selected and the tables itself but not the Tables node between them.

U can see it in the attached screenshot here.

Reproduced. It's tricky. It only occurs if you have no element checked it seems. The toggle apparently doesn't affect the parent's checkbox. We'll look into that.

BTW, something happend to the entity editor. If now first the type converter of the last row is selected the column does not adjust itself. Only if U change the type converter of the rows next to last or above. That was not in v3.1 I think.

Is this adjusting about resizing the column? The focus has to be set to a control other than the cell you're editing. Only then the column is set and thus the column is resized. But regardless: don't mix reports about things you run into, open a new thread and describe clearly what's to be done to reproduce this.

Hi Frans,

sorry, U R right. I'll not mix different things in one thread in future. But in order not to confuse it I'll answer a last time over here.

I do not set the focus first on the row where to change the type converter because that would be, IMHO, one unnecessary click more. Therefore I directly clicked on the last cell (I always start at the last row und work myself up) in order to open the combobox; select the wished entry and then click outside the grid in order to move the focus from the grid away. This is necessary each time because if U click directly to another cell the focus direcly moves back to the cell changed just before during resizeing and you'd have to click on the next cell again to open the combobox. It is more easy to click outside the grid.

Therefore I guess the event LostFocus is used instead of SelectedIndexChanged or SelectedValueChanged. In this case the UIElement calls again for the focus to do the resize. In case of the other events the event occures before the focus leave the element and the focus can not jump to and fro.

Again just my five cent...

Installing greetings

Reiner

Ok, we'll see if we can reproduce that, and if so, if there's anything for us to fix.

I've managed to fix the checkbox issue. It was a lot of cursing and fighting with event handlers tripping over each other in recursion, but it now works (fixed in next build).

The grid is a devexpress grid btw, and I can reproduce it: you click on another cell, the editor opens briefly, then the resize comes which closes the editor again. This is indeed rather silly, though it's to be seen whether we can fix it, as it might be a Devexpress xtragrid quirk...

Fixed in next build (may 29th). It was our mistake, or better: the result of event optimization. As a lot of events take place all over the model when some things change, it could really cause slow downs in the UI because elements get repainted over and over. So we added a 'throttler' (it's in algorithmia, very useful ) which raises 1 event instead of 1000-s of the same event per unique event caught in a given interval. The thing was that this event was handled by a method which always resized the grid properly. While that was OK, it occurred ~100ms after a cell was changed, and as it's on a timer, it was interrupting current execution, i.e. the editor that was opened by the user in the next cell -> resize took place, editor was closed.

We now resize the grid when one of the cells with a popup editor was changed right after the cell was changed. We also resize the grid as it was done previously, IF there's no active editor open (so when you click 'auto-new field' for example, and the grid has to resize automatically). Otherwise it doesn't resize it (As it has an editor open, which will resize the grid when the editor is closed and the cell is changed).

This affects usability for field mapping, sequences and type converters. Thanks for reporting this, as it makes a big difference in usability in this particular control

Hi Frans,

many thanks for that!

If I read this: what's about switching to WPF? Faster, different event model etc.?

And at the end at any time U will have to change because for MS WPF is the future. Of course, the old GDI+ model is really very old. Milcore is much faster as U can see on the Vista and Win 7 GUI that both use milcore.dll and therefore DirectX 9 and above.

Suggesting greetings

Reiner

rblock wrote:

Hi Frans,

many thanks for that! If I read this: what's about switching to WPF? Faster, different event model etc.?

WPF is dead, like Silverlight is. MS' future is WinRT / Metro, so XAML based UIs but not WPF. WPF was also a a total new game for us, as we have only done winforms. As we know winforms through and through, have many tools / libraries already at our disposal or written ourselves, it was really a time saver to go for winforms. Not to mention that back in 2008, when we started v3, WPF was also incredibly crap, with crashing designers in vs.net, blurry text etc. etc. So in the end, no regrets.

And at the end at any time U will have to change because for MS WPF is the future. Of course, the old GDI+ model is really very old. Milcore is much faster as U can see on the Vista and Win 7 GUI that both use milcore.dll and therefore DirectX 9 and above.

For normal UI it doesn't really matter much, the performance of the UI is normal as long as the # of events is kept below a threshold, as otherwise the numerous re-paints will cause extreme slowdown. This is also true for WPF, (which has other perf. problems as well) so to get a performing UI, you don't need WPF per se, you just need to limit the amount of work the UI has to do every second. Lots of stuff that happens behind the scenes fires 'I'm changed! If you show me in the UI, you should refresh yourself!', but if that happens a lot of times, you only have to repaint once, not every time

For the diagramming, it would have been better perhaps, although the main problem with diagramming is the graph layout algorithms. We wanted to add a layered modeler, so you can peel off layers of abstractions in the model, navigating deeper. This would have been great with WPF, with semi-transparent layers, but alas, maybe in the future