tkwizard

Discussion

(RFox) 28-March-2018 - this link is dead now.).

dbohdan 2018-03-28: Fixed.

(Bryan Oakley 04-Aug-2003: I'm a bit embarrassed that I've let that project go without an update for almost two years. But, truth be told, in that two years I've only had perhaps a half-dozen comments, so it seems there's not a whole lot of interest. If interest picks up I'll take the time to make my latest changes available. So, the project isn't dead, I just haven't felt motivated to complete the docs and update the examples to work with the latest bits).

MGS [2003/08/04] - Well, I created this page because I was surprised to find one didn't exist. I started writing a package installer application, which then turned into a wizard, and so I started looking at TkWizard. I would certainly be interested in seeing whatever changes have been made since version 1.0a1. I am actually quite interested in incorporating some kind of wizard into my eWidgets Toolkit, whether it's based upon TkWizard, or whether I rip the guts out of my package installer. I think I may be trying to do more than what TkWizard is capable of, but then I may just be guilty of not fully reading and understanding the docs. Maybe some better examples could help?

schlenk [2003/08/07] - TkWizard is nice, but a bit unfinished in some respects (so the alpha is quite appropriate). Some better examples and some more work on layout control/images would be really great. (As would usage of msgcat).

HaO 2010-10-19: Thank you, Brian, for TkWizard. I use it now since the start. Here are some experiences:

• Quite clever design, not much resorces needed
• The namespace and the window path are related. This makes it internally quick but has the drawback, that each call to a procedure of the contained module have to use full qualified namespaces. This is specially ugly, if msgcat is used:

$this stepconfigure -title [namespace eval ::select "mc infoOptionsTitle"]\
        -subtitle [namespace eval ::select "mc infoOptionsSupp"]\
        -pretext [namespace eval ::select "mc infoOptionsPre"]\
        -posttext [namespace eval ::select "mc infoOptionsPost"]

• The bind mechanism for the Next and Finish buttons are one for all pages. Often, I want to have a procedure called when a page is finised (by next or finish) to transmit the values. I use this code:

bind .parserawwiz <<WizNextStep>> {[%W namespace]::NextDo %W}
bind .parserawwiz <<WizFinish>> {[%W namespace]::FinalizeDo %W}
# Next dispatcher
.parserawwiz eval {
    proc NextDo {this} {
        set Step [$this cget -step]
        if {0 != [llength [info commands NextDo_$Step]] } {
            if { ! [NextDo_$Step $this]} {
                return -code break
            }
        }
    }
    #...
    # Page save function
    proc NextDo_Regexp {this} {
        return [RegexpTest]
    }
    proc FinalizeDo {this} {
        if {[catch {NextDo $this} Err dErr]} {
            dict unset dErr -level
            return -options $dErr
        }
        # save wizard changes
    }
}

• No syntax highlighting with Kommodo of the wizard code. Kommodo does not know, that there is code behind .parserawwiz eval and treats it as an argument.
• Long time ago, I have sent an msg-catted version of the wizard to Brian. He answered, that he will release a new version anyway, which never happened.
• One pitfall of the current implementation is that the same frame is reused for the client area of all pages. Only all client widgets are destroyed. If the widgets on the last page were managed by the grid manager, eventual row and column settings may propage from one page to the next. One may reset all settings after a page changing using gridClear from grid forget:

set c [$this widget clientArea]
gridClear $c

HaO 2011-06-06 I have a version ready, which allowed me to migrate to ttk. IMHO it is only suited for migration purposes and not so nice for new projects. If someone wants it, I may E-Mail it or place it somewhere...