tcl vs VB 6.0
ramien
Pick DataBasic as well.
MS in their infinite wisdon has decided to basically kill VB 6.0 with
.Net, which IMHO is pure $#^$. But that's another topic.
My question is:
Does tcl have the capabilty of generating a GUI look?
Secondly, is there an IDE that has tcl integrated and does it have the
same capability of creating Forms, buttons, check boxes, etc?
I'll worry about the drastic change in the programming language later.
ie. How to handle events, lookup information in a database, etc.
Thanks for any answers, input.
Ramien
Bryan Oakley
> I have been a programmer in VB 6.0 for years. I have programmed in
> Pick DataBasic as well.
> MS in their infinite wisdon has decided to basically kill VB 6.0 with
> .Net, which IMHO is pure $#^$. But that's another topic.
> My question is:
>
> Does tcl have the capabilty of generating a GUI look?
How do you define "a GUI look"? Tcl has Tk, which allows you to create
GUIs. It looks more-or-less like windows on windows, and unix on unix.
It sometimes requires an extension for certain classes of widgets (a
hierarchical tree and a combobox, for instance, aren't built in but are
readily available)
Through the option database or hard-coded options it is possible to
alter the look in many ways. It's probably safe to say that the Windows
look is close enough for pragmatists, but not close enough for the purists.
Tcl 8.5, which is in active development but already being used in at
least one commercial product (or so I've been told), will include an
extension named "tile" that provides a more robust themeing/style engine
that will allow more precise emulation of a Windows, Aqua or X11 "look",
as well as allow programmers to define their own look. Tile also
includes some addtional widgets missing in the core Tk distribution.
Examples of the results tile promises can be seen here:
http://tktable.sourceforge.net/tile
http://wiki.tcl.tk/ApplicationsUsingTile
There aren't any windows application screenshots in that second link,
but that's not because tile doesn't work on windows. It simply seems
that most early adopters aren Mac and Unix fans.
> Secondly, is there an IDE that has tcl integrated and does it have the
> same capability of creating Forms, buttons, check boxes, etc?
Most seasoned programmers seem to prefer to work without an IDE when it
comes to tcl/tk development, mainly because Tk is just so darned easy to
use an IDE would just get in the way. "Easy", of course, is highly
subjective.
If you want an IDE, there are a few alternatives. Start your research here:
http://wiki.tcl.tk/IDE
http://wiki.tcl.tk/GUIBuildingTools
Arguably the most polished is Komodo, put out by ActiveState
(www.activestate.com)
Best of luck! We'll be here when you're ready to make the switch.
ramien
I feel 'more comfortable' with a GUI; old habits die hard.
For example:
I create a form, add controls; labels, texboxes, dropdown lists and
combo boxes, menus and lastly a toolbar.
Then I go into the form load event and start adding code.
Then progress on to the textbox, listbox, menu and toolbar.
Each control has and event be it GotFocus or Changed or whatever.
I've downloaded the Komod Personal and will alsoo look at the
wiki.tcl.tk/IDE.
Perhaps later I will agree with on your statement, "Most seasoned
programmers seem to prefer to work without an IDE when it
comes to tcl/tk development, mainly because Tk is just so darned easy
to
use an IDE would just get in the way. "Easy", of course, is highly
subjective. "
But for now my comfort zone is the IDE.
I'll let you know how it goes.
Thanks again for your speedy reply to my posting.
Ramien
Peter Flynn
> I have been a programmer in VB 6.0 for years. I have programmed in
> Pick DataBasic as well.
> MS in their infinite wisdon has decided to basically kill VB 6.0 with
> .Net, which IMHO is pure $#^$. But that's another topic.
> My question is:
>
> Does tcl have the capabilty of generating a GUI look?
Yes, vTcl.
> Secondly, is there an IDE that has tcl integrated and does it have the
> same capability of creating Forms, buttons, check boxes, etc?
vTcl does this also.
> I'll worry about the drastic change in the programming language later.
> ie. How to handle events, lookup information in a database, etc.
The top-down approach gets me a lot of flak from other programmers too :-)
///Peter
Peter Flynn
> Thanks for responding so quickly.
>
> I feel 'more comfortable' with a GUI; old habits die hard.
As an old CLI programmer I'd have rated GUI as "new habits" :-)
> For example:
> I create a form, add controls; labels, texboxes, dropdown lists and
> combo boxes, menus and lastly a toolbar.
> Then I go into the form load event and start adding code.
> Then progress on to the textbox, listbox, menu and toolbar.
I'd prefer to code it by hand, but my requirement was to use it to study
the process of building a GUI using a GUI. And although I like the
expressiveness of Tcl code, it takes a fair amount of surrounding gunk
to enable even a 1-widget window to do something; and vTcl does that for
me.
> Each control has an event be it GotFocus or Changed or whatever.
> I've downloaded the Komod Personal and will alsoo look at the
> wiki.tcl.tk/IDE.
>
> Perhaps later I will agree with on your statement, "Most seasoned
> programmers seem to prefer to work without an IDE when it
> comes to tcl/tk development, mainly because Tk is just so darned easy
It would be if I had access to better documentation. The book I bought
is good, but it assumes a lot of foreknowledge, and it is *very* sparse
on detail: for example it disposes of if-then-else in just over one page,
without giving any examples beyond the trivial, and without even
mentioning compound conditions either there or in the index, so I had to
take an educated guess that "and" was && and "or" was ||. Tk isn't really
"darned easy", but it certainly isn't difficult: it's just quirky and
highly idiosyncratic, but once you get into the swing of it, it's great.
> to
> use an IDE would just get in the way. "Easy", of course, is highly
> subjective. "
> But for now my comfort zone is the IDE.
I've learned more by examining the code that vTcl produces than I ever
would have by just learning the specific commands I thought I needed.
///Peter
Jeff Godfrey
"Peter Flynn" <peter...@m.silmaril.ie> wrote in message
news:3p4ucfF...@individual.net...
>And although I like the
> expressiveness of Tcl code, it takes a fair amount of surrounding gunk
> to enable even a 1-widget window to do something; and vTcl does that for
> me.
Hmmmm... I don't know what your definition of "do something" is, but here's
a single widget window that "does something"- and I don't know how it could
be much simpler...
catch {console show} ; # in case you're on Windows and running wish...
pack [button .b1 -text "Press Me" -command {puts "I was pressed"}]
> It would be if I had access to better documentation. The book I bought
> is good, but it assumes a lot of foreknowledge, and it is *very* sparse
> on detail: for example it disposes of if-then-else in just over one page,
> without giving any examples beyond the trivial, and without even
> mentioning compound conditions either there or in the index, so I had to
> take an educated guess that "and" was && and "or" was ||. Tk isn't really
> "darned easy", but it certainly isn't difficult: it's just quirky and
> highly idiosyncratic, but once you get into the swing of it, it's great.
What book are you using? Are you aware of the Wiki? It contains a wealth
of knowledge. For example, searching for "if" there reveals (among other
things):
That page also reveals a link to the if man page -->
http://www.tcl.tk/man/tcl8.4/TclCmd/if.htm
I don't know what platform you're on, but the help file provided with
ActiveTcl is quite good (and just a re-packaging of the standard man pages
I'd assume).
There's also comp.lang.tcl for when you're really stuck...
Jeff
Ian Bell
> ramien wrote:
>
>> I have been a programmer in VB 6.0 for years. I have programmed in
>> Pick DataBasic as well.
>> MS in their infinite wisdon has decided to basically kill VB 6.0 with
>> .Net, which IMHO is pure $#^$. But that's another topic.
>> My question is:
>>
>> Does tcl have the capabilty of generating a GUI look?
>
> Yes, vTcl.
>
>> Secondly, is there an IDE that has tcl integrated and does it have the
>> same capability of creating Forms, buttons, check boxes, etc?
>
> vTcl does this also.
>
Unfortunately vTcl is incomplete, broken and has not been developed for a
couple of years.
Ian
Dennis LaBelle
Take a look at my TKproE home page at http://tkproe.sourceforge.net/
It a fairly decent and relatively up-to-date GUI builder for TCL/TK.
Dennis LaBelle
Rob
news:1126993168....@z14g2000cwz.googlegroups.com...
>I have been a programmer in VB 6.0 for years. I have programmed in
> Pick DataBasic as well.
> MS in their infinite wisdon has decided to basically kill VB 6.0 with
> .Net, which IMHO is pure $#^$. But that's another topic.
I too worked with VB for quite a few years and also decided that the .NET
version was too similar and too different at the same time to bother with so
I stayed with the VB "Classic"(5 & 6) and later started working with other
languages since I wanted multi-platform capability [Linux & Windows] - then
I found Tcl/Tk!
> My question is:
>
> Does tcl have the capabilty of generating a GUI look?
Definitely does - Its called Tk and it is now delivered as part of the core
language.
> Secondly, is there an IDE that has tcl integrated and does it have the
> same capability of creating Forms, buttons, check boxes, etc?
I've looked at Visual Tcl - application development environment. See
http://vtcl.sourceforge.net/
> I'll worry about the drastic change in the programming language later.
> ie. How to handle events, lookup information in a database, etc.
I've got a few other URLs which should help you with getting used to Tcl/Tk:
A graphical and interactive debugger for Tcl-TK
http://gid.cimne.upc.es/RamDebugger/RamDebugger_toc.html
TCL Tutor http://www.msen.com/~clif/TclTutor.html
Regarding the vtcl IDE, I found it pretty confusing although the code it
generates is very useful in learning about GUI bindings and such. For what
I have done the GUIs are very simple and hand building them worked well.
Using RamDebugger was very useful for learning how the language works and
actually getting code to work correctly. I've used it as a sort of IDE for
tcl code development and checking how the tk code works too! RamDebugger
displays tcl/tk help in context of the current command as well as general
language help - IMO a vital development tool.
Finally the VB6 To Tcl mini-HOWTO to make the transition to tcl/tk less
painful - http://www.faqs.org/docs/Linux-mini/VB6-to-Tcl.html
As a general reference, the Tcler's Wiki is absolutely brilliant:
http://wiki.tcl.tk/. Contributions cover almost any aspect of development
techniques and approaches you'd want to find.
HTH
Rob.
ramien
I just sent you an e-mail as I have downloaded vtcl and really like
what I see.
It looks pretty intuitive as I said in the e-mail.
I hope that vtcl is going to work. I'd hate to have work 90% of the
way and the 10% lacking is what I need.
ramien
ramien
GUI aspects of tcl/tk.
I am going to try vtcl and see what happens.
I really look forward in the future to corresponding with you all when
I have a real hangup.
What do guys think about using MySQL as a database?
The program I am converting, or at least implementing, is a VB projoect
with a couple hundred subroutines and 50-60 windows. Most of them are
always going to a database to get the information.
This is a TechSupport app I wrote over the period of years.
ramien
Ian Bell
Just be aware that vtcl is not currently being developed.
Ian
Synic
> Most seasoned programmers seem to prefer to work without an IDE when it
> comes to tcl/tk development, mainly because Tk is just so darned easy to
> use an IDE would just get in the way. "Easy", of course, is highly
> subjective.
That's precisely why TCL/Tk gelled with me where other GUI languages
didn't. No distracting IDEs and a structure simple enough to create
programs out of text files.
The way I explain my interest in TCL is this: imagine if there were a
GUI language much faster than Java, much more cross platform than C++
and its variants, easy enough to write code straight from text files,
well supported by both commercial vendors and the Open Source community,
with a long history of use dating back to the 1980s. That's TCL.
Just the fact that, with ActiveState's TDK, I can distribute binaries
with all the DLLs/libs I need wrapped inside in the binary's own VFS,
has made life so much easier than were I using something else.
The other great plus is, of course, this comp.lang.tcl newsgroup. Lots
of handy suggestions and hints when you need them :-).
Synic
> It would be if I had access to better documentation. The book I bought
> is good, but it assumes a lot of foreknowledge, and it is *very* sparse
> on detail: for example it disposes of if-then-else in just over one page,
> without giving any examples beyond the trivial,
Definitely, the best book for beginners is "Practical Programming in Tcl
and Tk" by Brent B. Welch, Ken Jones and Jeffrey Hobbs. Very handy as a
reference once you're past the fundamentals too. My copy's getting a lot
of wear :-).
Peter Flynn
> You guys are too much. You've sent me so much information about the
> GUI aspects of tcl/tk.
> I am going to try vtcl and see what happens.
If what Ian Bell posted is true (and I have no reason to believe otherwise)
then vTcl is incomplete and broken and I shouldn't be using it. It would
have been nice to know this at the time I started, but I didn't see anything
about it at the time. Fortunately I'm not using it for anything mission-
critical.
Which is a pity. Tcl could probably do with a reliable GUI development
platform.
> What do guys think about using MySQL as a database?
It works on the very rare occasions when I use it.
> The program I am converting, or at least implementing, is a VB projoect
> with a couple hundred subroutines and 50-60 windows.
50-60 screen designs?
> Most of them are
> always going to a database to get the information.
For performance, minimising the number of hits on the database is
usually regarded as A Good Thing.
///Peter
Ian Bell
> If what Ian Bell posted is true (and I have no reason to believe
> otherwise) then vTcl is incomplete and broken and I shouldn't be using it.
Judge for yourself. The sourceforge site posted the last version in August
2003 and the forums are similarly sparse.
> It would have been nice to know this at the time I started, but I didn't
> see anything about it at the time. Fortunately I'm not using it for
> anything mission- critical.
>
I did mention it in reply to another post in this thread. Also another
poster mentioned tkproe which is just as good and currently still being
developed.
Ian
ramien
Peter,
Yes I have about 7-8 projects;
Setup User and database path.
Define what parts are used.
Define what equipment is used.
Add/Modify clients.
Open calls.
Send mail.
Change fonts.
Change colors/backgrounds.
Some projects have 20+ windows; not all used at the same time. Some
are for reviewing old calls, correcting SQL problems, displaying calls,
etc.
Each time a call center rep gets a call he looks up the client and
opens the call. End of Database query. Update occurs when leaving the
call.
If he/she wishes to review all the old calls, then database query. If
they wish to look at the previous call while in a call, database query.
The application is spit-quick. No unnecessary queries and minimal
overhead.
Just thought I'd fill you in on what the application was.
ramien
Dennis LaBelle
I think Ian Bell's description of vTcl is the best one:
"Unfortunately vTcl is incomplete, broken and has not been developed for
a couple of years."
I have been writing GUI applications for over 15 years. I used (heavily) and
maintained the XF GUI builder for TCL/TK for seven years. I then wrote and
released TKproE last year. I have also been programming much Visual Basic
for the last 6 years.
I have to say that I find vTcl to be terribly incomplete, lacking in
significant documentation and not something that I would want to use to put
together any sizeable program.
Michael A. Cleverly
> What do guys think about using MySQL as a database?
> The program I am converting, or at least implementing, is a VB projoect
> with a couple hundred subroutines and 50-60 windows. Most of them are
> always going to a database to get the information.
> This is a TechSupport app I wrote over the period of years.
If the application runs locally I'd suggest using SQLite. See:
http://sqlite.org
http://wiki.tcl.tk/sqlite
http://sqlite.org/tclsqlite.html
Michael
Nicolas Boretos
The original poster should also be aware of Postgres
and if you use Michael's nstcl package for your db calls,
you have the option of using several backends without (any?) changes to
your logic, e.g. develop using sqlite and migrate to an rdbms later..
Michael is too modest ;-)
regards,
nicolas
Wojciech Kocjan
> You guys are too much. You've sent me so much information about the
> GUI aspects of tcl/tk.
> I am going to try vtcl and see what happens.
>
> I really look forward in the future to corresponding with you all when
> I have a real hangup.
>
> What do guys think about using MySQL as a database?
I'd suggest PostgreSQL or SQLite for local databases.
> The program I am converting, or at least implementing, is a VB projoect
> with a couple hundred subroutines and 50-60 windows. Most of them are
> always going to a database to get the information.
> This is a TechSupport app I wrote over the period of years.
You might want to try my TclDB package. It features db-independant
database layer (similar to nstcl), a lot of GUI widgets and a cool
tdbedit class that lets you set up list(s)+ edit tabs in under 50 lines.
It also features a nice SQLite based configuration, which allows you to
use Tcl variables for configuration and let TclDB store it.
http://sourceforge.net/projects/dqsoftware/
It's not 1.0 yet, but mostly because I don't have time to finish the
documentation.
ps. For all of you Oracle fans - Oracle support is in CVS now. Even a
TclDB-like transaction support.
(oradb transaction {something 1; something 2; something 3; ...})
-- WK
Cameron Laird
Synic <flavp+...@nhgbaf.arg.nh> wrote:
.
.
.
>Definitely, the best book for beginners is "Practical Programming in Tcl
>and Tk" by Brent B. Welch, Ken Jones and Jeffrey Hobbs. Very handy as a
>reference once you're past the fundamentals too. My copy's getting a lot
>of wear :-).
>
I definitely don't agree--at least, not without qualification.
*Practical Programming ...* is great for those with a strong
background in languages, who are starting with Tcl. If an
astronomer, though, let's say, or perhaps an analytical scholar
of Persian poetics, were trying to figure out whether Tcl might
be useful, *Practical Programming ...* would be a poor fit.
For more details, see, for example, <URL:
http://www.unixreview.com/documents/s=8887/ur0309l/ >.
Cameron Laird
ramien <ram...@oriok.net> wrote:
.
.
.
>What do guys think about using MySQL as a database?
>The program I am converting, or at least implementing, is a VB projoect
>with a couple hundred subroutines and 50-60 windows. Most of them are
>always going to a database to get the information.
>This is a TechSupport app I wrote over the period of years.
.
.
MySQL certainly is up to such a task.
While MySQL is exceedingly popular among many respected practitioners,
the comp.lang.tcl crowd favors Postgres, sqlite, and metakit. Tcl is
quite happy to work with any of these, and more. You are free to choose
your datamanager with confidence that Tcl will do its part.
Would it help you to start your rework while retaining the database
you've already been using with VB? Were you running your VB-coded app
against Jet, perhaps?
You're going to end up being sooooooo much happier with sqlite or
Postgres or ...
Cameron Laird
Peter Flynn <peter...@m.silmaril.ie> wrote:
.
.
.
>If what Ian Bell posted is true (and I have no reason to believe otherwise)
>then vTcl is incomplete and broken and I shouldn't be using it. It would
>have been nice to know this at the time I started, but I didn't see anything
>about it at the time. Fortunately I'm not using it for anything mission-
>critical.
>
>Which is a pity. Tcl could probably do with a reliable GUI development
>platform.
.
.
While I think this thread as a whole makes it clear, I feel
compelled to put it in explicit words: Tcl *does* enjoy "a
reliable GUI develoment" facility. Several, in fact, among
<URL: http://wiki.tcl.tk/4056 >.
Michael A. Cleverly
> and if you use Michael's nstcl package for your db calls,
>
> http://nstcl.sourceforge.net
>
Thanks for the nstcl plug, btw. :-)
> you have the option of using several backends without (any?) changes to your
> logic, e.g. develop using sqlite and migrate to an rdbms later..
The only changes you would need to make (assuming you don't use any
non-standard SQL extensions that another vendor does not support) would be
two lines:
nstcl::load_driver <different-database-type>
and
nstcl::configure_pool <db host name, port, username, password, etc.>
otherwise everything else should "just work".
Michael
yahalom
does not handle the differences in databases. for example create
script,dates,sequences etc. it also have bad performance with large
amount of data. we developed our own database layer due to these
problems.
http://mini.net/tcl/10046
Wojciech Kocjan
TclDB does not have this problem (tested on fetching about 50k rows).
I see you used a very interesting approach of storing function names as
variables. I however think that inheriting would be better, since it's
still Itcl method and not a proc with upvar statements.
--
WK
Michael A. Cleverly
I believe it is correct, with the caveat (that I made in my previous
message) that you are sticking to generic SQL that is portable across
databases. Differences in DML and data-type handling, etc., can obviously
be a problem. nstcl makes absolutely no attempt to transform one vendors
SQL-dialect to another.
The original intent was to model the AOLserver database API's _exactly_ so
that code could be reused between AOLserver/OpenACS and tclsh/wish without
any changes whatsoever (aside from a line or two preamble to setup the
environment). That requirement does lead to a lot of wrapping--to support
both the AOLserver ns_db and ns_set APIs, as well as the OpenACS db_* api.
Admittedly it can become an issue with very large data sets due to the
design objective of supporting both APIs. Admittedly you could create a
new API from scratch--which you have done--that does much less wrapping
(and hence would have much greater performance). Thanks for making the
code available on the wiki. It's always nice to have alternatives.
Michael
jus...@zeusedit.com
If you need an IDE for the Windows platform then take
a look at Zeus:
http://www.zeusedit.com/features.html
As a language neutral IDE, Zeus offers many generic
features like class browsing, syntax highlighting, smart
indent, code folding, project/workspace management,
integrated version control etc etc.
Note: Zeus is shareware (45 day trial).
Jussi Jumppanen
Author: Zeus for Windows
yahalom
dbConnect db
db loadDriver
db sql "select..."
I do not want the user to write:
oracle db
db sql
also the odbc-oracle and oracle are almost the same and should not be
in different classes.
itcl does not support dynamic inheritance or mixins so inheritance
seems to me cumbersome.
Wojciech Kocjan
> how would you create inheritance that support this simple usage:
> dbConnect db
> db loadDriver
> db sql "select..."
> I do not want the user to write:
> oracle db
> db sql
Write a wrapper proc. Not sure what you are trying to overcome, but it
seems weird to me.
proc dbConnect {name} {
oracle $name
}
I have a tcldb::config package which (among many) initializes a database.
It might be considered a wrapper, because you can just put in the database
name (sqlite by default - seems logical to store local configuration in a
local database).
> also the odbc-oracle and oracle are almost the same and should not be
> in different classes.
Well that's very not true. Their SQL is the same, but the interface is
very different. So I have one interface for ODBC and oratcl and
schema_oracle, which defines handling via variables.
> itcl does not support dynamic inheritance or mixins so inheritance
> seems to me cumbersome.
I use static inheritance and variables for parameters. TclDB could talk
DB-local dialect. In fact I have a synchronization package on top of (not
opensource) it which gets possible trigger creation modes (only for sqlite
and postgresql) and I used schema for that. For example SQL for oracle
odbc is very different from SQL for sapdb (is it maxdb now?)...
Interface (Tcl API) is something different than DB functionality.
If you really need to have both DB functionality and Interface without
helper variables (which isn't really a PITA in speed) then do cross
inheriting:
class {odbc-oracle inherit interface-odbc schema-oracle}
class {oratcl-oracle inherit interface-oratcl schema-oracle}
class {odbc-mysql inherit interface-odbc schema-mysql}
And so on. But I use -schema public variable, which is set to a sensible
value in the constructor (except for odbc API).
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/