Will the SQLite3UI units set become TMS-independent?

migajek · 2010-11-29 21:27:23

Hi,
I like the idea of SQLite3UI units, but what I dislike about them is their dependency on TMS components. It's a pity that there's no possibility to use them without those commercial externals...
Is there any plan for some alternatives?

Thanks,
m.

ab · 2010-11-30 07:12:09

It's on my road list.

I'd like to use the Ribbon component, as available since Delphi 2009. But I heard it was buggy... perhaps it's fixed in XE.
Another possibility will be to create a regular tab set with toolbars, to emulate the ribbon layout. 100% efficient and work for all version of Delphi, but perhaps less attractive.
What's your opinon/feedback about those two proposals?

Stay tuned!

migajek · 2010-11-30 11:30:57

My main development environment for all the "private" (hobby) projects is Delphi 7 (Personal edition!) ..
That makes Synopse SQLite3 most complete and powerful DB framework available Of course I'm fully aware that I'm in minority, and I'll have to switch to more recent Delphi version one day.

Besides that, personally I don't like ribbon idea at all. I hate using Office 2007 just because it has ribbon instead of menus & toolbars. I don't get the idea of Ribbon, and don't know any advantages over menus & toolbars, except for bigger icons in Ribbon

Have you considered optional dependency on SpTBXLib which is a mature, customizable, attractive-looking MPL-licensed set of menu & toolbars components (based on Toolbar2000)?

ab · 2010-11-30 15:33:17

The "ribbon" aspect of the UI generated by the framework is much more familiar than the Office 2007 program.

See the MainDemo, and the screenshots available from http://blog.synopse.info/post/2010/08/0 … Demo-draft

My intend is to implement it with either TMS components, either with regular TTabSet+TToolBar components. You will able to switch from one to the other with compilation conditionals.

I didn't know about SpTBXLib.
I used TB2K in another applications, but I don't see in what it could be better than the regular TToolBar component for the UserInterface the framework need to generate.

migajek · 2010-11-30 16:58:43

Hi,
I thought you're main point against native TToolBar & TTabSet is a poor look of those old components. SpTBXLib provides skinning support for TB2K (but not only, of course).
Anyway, I'd love to see the code which compiles under old Delphi with no dependencies on commercial component sets

ab · 2010-12-01 07:01:11

TTabSet was not so poor. There is some kind of skinning, according to the Windows color scheme, if you use native buttons.

Of course, I do understand your concern about dependency on commercial sets...

I'll do my best to make this dependency optional.

ab · 2010-12-01 07:56:26

The Demo application idea is great!

What about using our Grid component?
It's not bundled to the TMS software, and it's definitively powerful.

See http://synopse.info/forum/viewtopic.php?pid=644#p644

Worth showing it in the demo, IMHO.

migajek · 2010-12-01 10:41:57

ab wrote:

The Demo application idea is great!
What about using our Grid component?
It's not bundled to the TMS software, and it's definitively powerful.
See http://synopse.info/forum/viewtopic.php?pid=644#p644
Worth showing it in the demo, IMHO.

Hi,
indeed, so far I haven't played with UI classes at all, I just thought all of them depend on TMS.
As I can see, the TSQLTableToGrid can't use TSQLRestServerDB directly, I had to export it via named pipe and than create a client - just for TSQLTableGrid to access it. Is that really necessary?
Anyway, it's definitely worth showing but I won't commit it unless you tell me why does it require the URIClient to be created & used

ab · 2010-12-01 12:50:23

For a stand-alone application, you should use TSQLRestClientDB and not TSQLRestServerDB directly. TSQLRestClientDB will create an hidden TSQLRestServerDB instance, and will use it directly (with no client/server approach).

So you'll be able to upgrade to a Client/Server application just by changing the class type from TSQLRestClientDB into another TSQLRestClientURI, according to the transmission you want to use (named pipes, GDI messages, HTTP/1.1).

But since TSQLRestClientDB inherits from TSQLRestClientURI, your code will be able to use all UI and other related parts of the framework.

This was not obvious from the Sample supplied, but documented as such in the code.

migajek · 2010-12-01 14:11:50

Hi,
indeed that was a bit unclear - since the demo 02 used the server directly. Unfortunately I'm the kind of guy who looks at the examples first, than refers to the documentations when needs to clarify something

I've changed the code to follow the correct pattern.

Also, the demo shows TSQLTableToGrid as well now

BTW please have a look at line 402 of current revision (r4). In my case, using the Iso8601Now instead of Now, causes "Invalid floating point operation", pointing the method

procedure DateToIso8601PChar(Date: TDateTime; P: PUTF8Char; Expanded: boolean); overload;
// we use YYYYMMDD date format
var Y,M,D: word;
begin
  DecodeDate(Date,Y,M,D);
  DateToIso8601PChar(P,Expanded,Y,M,D); // <-- debugger points that line.
end;

ab · 2010-12-01 14:23:43

migajek wrote:

BTW please have a look at line 402 of current revision (r4). In my case, using the Iso8601Now instead of Now, causes "Invalid floating point operation", pointing the method

DateToIso8601PChar() expect a TDateTime parameter, not a Iso8601 parameter.
Those are two diverse types, with diverse values.

TDateTime is the Delphi standard Time/Date, which is a double.
Iso8601=TTimeLog is an Int64, containing the Time/Date as bit shifts.
The problem is that you can pass a Int64 as a TDateTime=double, in the Delphi compiler, therefore you use the wrong function with no compiler error...

The framework uses Iso8601 or TTimeLog instead of TDateTime because it's much faster, and SQLite3 likes better Int64 values than double values.

So use Now if your property is a TDateTime.
And uses Iso8601Now if your property is a TTimeLog

migajek · 2010-12-01 14:25:48

ab wrote:

The framework uses Iso8601 instead of TDateTime because it's much faster, and SQLite3 likes better Int64 values than double values.

thanks, my bad

JonG · 2010-12-01 16:21:53

migajek wrote:

Hi,
indeed that was a bit unclear - since the demo 02 used the server directly. Unfortunately I'm the kind of guy who looks at the examples first, than refers to the documentations when needs to clarify something
I've changed the code to follow the correct pattern.
Also, the demo shows TSQLTableToGrid as well now

I am interested in looking at that demo. Where is it available?

Thanks!

migajek · 2010-12-01 16:32:32

Currently it is available in SVN only, at the

http://code.google.com/p/synopse-sqlite-demo/

but I'll upload the zip archive in 15 minutes

mORMot Open Source

#1 2010-11-29 21:27:23

Will the SQLite3UI units set become TMS-independent?

#2 2010-11-30 07:12:09

Re: Will the SQLite3UI units set become TMS-independent?

#3 2010-11-30 11:30:57

Re: Will the SQLite3UI units set become TMS-independent?

#4 2010-11-30 15:33:17

Re: Will the SQLite3UI units set become TMS-independent?

#5 2010-11-30 16:58:43

Re: Will the SQLite3UI units set become TMS-independent?

#6 2010-12-01 07:01:11

Re: Will the SQLite3UI units set become TMS-independent?

#7 2010-12-01 07:56:26

Re: Will the SQLite3UI units set become TMS-independent?

#8 2010-12-01 10:41:57

Re: Will the SQLite3UI units set become TMS-independent?

#9 2010-12-01 12:50:23

Re: Will the SQLite3UI units set become TMS-independent?

#10 2010-12-01 14:11:50

Re: Will the SQLite3UI units set become TMS-independent?

#11 2010-12-01 14:23:43

Re: Will the SQLite3UI units set become TMS-independent?

#12 2010-12-01 14:25:48

Re: Will the SQLite3UI units set become TMS-independent?

#13 2010-12-01 16:21:53

Re: Will the SQLite3UI units set become TMS-independent?

#14 2010-12-01 16:32:32

Re: Will the SQLite3UI units set become TMS-independent?

Board footer