On Tue, 19 May 2009, Graeme Geldenhuys wrote:
Hi Michael,
I decided to ask the questions in the mailing list, seeing that
LazDataDesktop is shipped with Lazarus (instead of emailing you
directly). That way, if others are using LazDataDesktop, they can
comment if they wish.
* What is the best way to extend the "export as source" dialog. I see
you a "register a new export operation" in the initialization section
(eg: export as tiOPF), but what would be the best way if I wanted my
own export options - maybe not included in LazDataDesktop for some
reason? Do I just hack LazDataDesktop myself and create my own custom
version?
You can register any dialog for any export operation. Just create the
dialog, and register it in the unit itself, add the dialog unit to the
project, recompile. That should be it.
* What is the best way to add new "export as source" option. I want to
add an option for "tiOPF - export as DB independent visitors" as well.
Should I try and extend the "export as hard-coded visitors" with some
toggle option, or should I just create a new export unit? I am leaning
to the new export unit, because many options do not apply to "DB
independent visitors".
I was going to suggest that.
* Is it by design or an oversight that there is no option or warning
that "auto-commit" is not enabled in the "Run Query" window. It took
me a while to figure out why my data is visible one moment, and then
later it's gone. At the moment I have to explicitly run a query
"commit;" to save any changes. Not a big deal - if you know you have
to do it.
Adding a commit button was on my todo-list.
An Auto-commit option also. (amongst some others)
* I remember I told you before (but can't remember your answer) that
the order of the fields are incorrect under Linux using LazDataDesktop
compiled with GTK1 or GTK2, but correct when compiled with Win32. Also
you have the up/down buttons to reorder the fields, but again it
doesn't work under GTK1 or GTK2, but does under Win32. What was the
cause of that bug? LCL TListbox bug?
This is a LCL TCheckListbox bug.
If the items are ordered, the associated objects are not.
(I think the same applies to combobox and listbox)
* I see you have added a new "single save visitor" for tiOPF. This is
a nice idea and saves a lot of code, but that also means you cannot
control the order in which saving occurs. The most stable saving
order, after numerous testing loooong ago, is Delete, Update, Insert.
But with that single save visitor you cannot control that - or am I
missing something?
I am aware of the ordering importance.
Why shouldn't you be able to control that with the single save visitor ?
If I'm correct, you can determine what operation is currently in progress,
and hence should be able to check for states that should be saved.
Michael.
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
