[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vtcl-user
Subject:    [vtcl-user] My experience with vtcl
From:       Eric Taylor <et () rocketship1 ! com>
Date:       2002-08-02 0:22:53
[Download RAW message or body]

At 12:28 PM 08/01/02 -0700, you wrote:
>Send vtcl-user mailing list submissions to
>
>
>As for people not using the GUI development tool and going directly to Tk,
>it's probably because they get more flexibility in hand-writing the code
>themselves, and more security as well, since a GUI builder (vTcl included)
>can corrupt the whole project because of a bug (don't forget vTcl always
>makes a backup copy, though, so you can recuperate from crashes).

Let me be the first to add my 2 cents: 

I write all my gui code in vtcl. Yes, there are a few problems,
but I am in the habit of making a copy  before writing the file out from vtcl. 
I never lose work.  

One thing though, I rarely use the test mode on my programs. I always prefer to
minimise vtcl, and run outside of vtcl. I am not sure, but it feels
much more reliable this way. 

I write most procs using visual c++ as my editor. When I use
vtcl, it is normally to just set up the gui, with all callbacks being a
separate proc. I might create the proc in vtcl, but then I switch to
edit mode in vc++. I often keep both going at the same time. Making only
gui changes in vtcl, then writing all procedure code in vc++. I have many
vc++ toolbar macros that create template code blocks, for various types
of if-else-elseif, or foreach, for-loop, etc.

When I test my code, I open a console window. I have
a vc++ toolbar macro that can find and copy (to clipboard) the procedure
I have the cursor in. Then with one or two more clicks, I can paste it
into the console window. This way I don't even need a fancy debugger. Just
add some puts statements, re-load the modified proc, continue. By putting interesting
variables in global, and using a global dumper proc I wrote, debugging is
a breeze. With vtcl's aliases that build a new tcl proc for each widget, it
it trivial to see the active state of any widget. Just enter "Button1 configure"
as an example. A few simple procs can make this even easier to see.

I also make editing changes on the vtcl output itself, since it's just
tcl code and the beauty of vtcl is that there are no intermediate files,
like in visual c or visual basic. Sometimes it is just easier to change
something for 5 widgets using an editor. Or searching the code making
a global change. Vtcl never knows or cares, as long as you don't change
the wrong thing. But I never seem to have that problem.

Because of the dual use, I have a shortcut on the desktop to reload vtcl
and my project with a single click. Vc++ remembers on entry the last
project and even the location you last edited. So, I get best of both
worlds.

Also, I am considered the gui expert where I work, since often I can
create a new program gui in under an hour with vtcl. But then I cheat and take the
rest of the day off and let them be amazed it only took me 1 day. And I love
saying: "Oh, btw, it's portable too!"



 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
vtcl-user mailing list
vtcl-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vtcl-user
[prev in list] [next in list] [prev in thread] [next in thread]