Zugg Software :: View topic

Magician Joined: 13 Oct 2000 Posts: 463

Many of the problems with disappearing settings and crashes when you delete or alter settings appears to be related to the fact that the Package Editor refuses to have NOTHING selected. When I delete a setting, it will leap to some other spot in the list and show another setting.

Why not make this (relatively) simple change... if the current setting is no longer a valid target to display, then display nothing. On the left make nothing be selected, and on the right show a blank pane (perhaps with the text 'Nothing Selected').

If I move a setting and anything would prevent the editor from displaying the same setting to me (it was deleted, got moved to a different package that is not in the current view, whatever) select and display nothing.

I think this would solve many of the timing issues, and it would also be easier to use in general... currently, the cursor can really get crazy jumping around to odd settings as you move or delete stuff. Better to not change the view at all and select nothing.

Posted: Tue Nov 21, 2006 11:47 pm

There is no way to do this. The package editor is essentially a database viewer. And when viewing a database, there is *always* an active record (unless the database is empty). The problems with the cursor jumping around is a bug and is being fixed in 1.16. There are several bugs with deleting settings in 1.15.

Anyway, the problem just isn't as simple as you think. The problem is that the tree-view is getting out-of-synch with the current database record, because of the performance tricks that I'm playing. If you used older beta versions, you'll remember how slow CMUD was when the settings editor was open. This is because the tree was forcing itself to stay in synch with the current database record. Any change in the database would cause the tree to update, which made it very slow.

In the newer betas, I've kludged the tree so that it doesn't need to stay in synch with the database and doesn't need to reload itself whenever the database changes. This resulted in a trememdous speed improvement, but had the side effect of the tree getting out of synch with the database, which could then cause crashes.

I'll probably eventually replace the tree view with something that I write myself, but that's a huge job and not something I'm willing to do before the public release. So right now I'm just trying to patch the existing code the best that I can whenever I find a problem where the tree gets out of synch.

Anyway, just displaying nothing wouldn't actually help.

Magician Joined: 13 Oct 2000 Posts: 463

When you display a record in the Package Editor, you're linking the value of several GUI controls into the fields in that record. Drawing the controls (especially if you just changed from one type of setting to another), putting the data in it... that's slow. And I do find it difficult to believe that it's required. There may be an active record in the database component, but that does not mean you are required to draw all the GUI controls needed to interact with it. If the current record was just deleted, you could simply turn on a flag to tell the right hand pane to display the 'no active record' blank screen, and unselect anything in the tree control on the left. The database cursor might still be pointing to something, but if the GUI ignores it then it won't slow down the screen, or get unsynced, or write back unsynced data.

And when the user clicks on a setting on the tree control, you clear the 'draw nothing' flag and start updating the right hand pane again.

I'm sure there's numerous reasons why this is more complicated than I think, but it doesn't SEEM like it should be hard.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I do what The Raven does with my DB-enabled projects, but I don't use a live treeview control the same way that CMUD does... I query the database on demand, eg if I open "products" do a "select id, name from products" and populate the TTreeNodes with the caption set to the product name and the Tag field set to the ID.

Then when someone highlights a product in the tree, I show the ProductEditor panel and do a "select * from products where id = SelectedTreeNode.Tag" and populate the edit boxes at that point.

If nothing or the 'root' node is selected I show a placeholder panel which has the company logo and a few statistics, just to make it pretty.

But I build my apps using this methodology from the start, and it took a while to get working properly, so yeah I agree, while it's a simple concept it isn't something you want to be modifying this late in the beta... it can be on the 1.30 or 1.40 wishlist :)

Posted: Wed Nov 22, 2006 5:47 pm

Actually Raven, that isn't quite right. That's the way the settings editor *used* to work. But in the later versions, none of the controls that you see in the settings editor are "bound" to the database anymore, except the Tree View on the left.

And as I said above, I realize the problem with the Tree View and plan to replace it in the future with a non-databound control. But doing this will be a lot of work and will introduce plenty of new problems. The reason I stuck with the data-bound tree view is because it makes doing filters and searches and drag/drop relatively easy. It has a lot of nice features that I'll have to code myself into a non-bound tree. And then I'll still be left with the issue of updating the tree and making sure it stays in sync with the database.

Keep in mind that most programs (like what Rainchild described) don't have changes being made to the "live" database while you are editing. Most database applications are designed so that when a record is changed by another user, you don't see it until you refresh your data view. The concept of having the tree view change as settings are added or removed by scripts running in the background isn't something that a normal database application deals with.

Magician Joined: 13 Oct 2000 Posts: 463

Gotcha, thanks for the explanation Zugg.