P
Patrick Tingen
Guest
After my post I dived in again and explored the option with suppress-window. Actually, in my first attempts I was trying to overcomplicate things so it could be done simpler. And more simpler is more better 
I have now created a window to serve as the host for the frames that make up the steps of the wizard. In my test I used 3 steps, but it is plain easy to extend it. The window is wizard.w, the individual steps wizardsub1.w to 3.w. In the window, I start the underlying .w files persistently. These are set up to suppress-window = yes and have an output parameter that gets filled with the frame handle. This handle is saved in a temp-table in the window and is used to hide/view/move the frame around. I added a counter to the temp-table and two extra buttons for 'next' and 'previous' that use this counter to walk through the screens. A simple FOR-EACH will hide or view the steps. To overcome the problem of having to click the close button multiple times, I let the windows accept a handle to the parent procedure (the main window). A close event is then applied to the parent instead of to the child, so if you close the parent window, it closes at once. It works quite well. Actually, I should have used a dialog instead of a window, but that's a minor thing. Next thing is how to handle updates to the database. Since the steps are individual programs, they need to have a common source for the data if they need to react on each others state. A database will do, but it means that changes by the user cannot be cancelled; if you do something in step 1, it must be recorded in the database otherwise step 2 will not know of it. But it implies that every step you do as a user is immediately recorded in the database. But you might want to undo what you did in the wizard, so I need a better solution. One may be a dataset that is controlled in the window and shared with the children. If anyone is interested, I can throw it on GitHub
Continue reading...
I have now created a window to serve as the host for the frames that make up the steps of the wizard. In my test I used 3 steps, but it is plain easy to extend it. The window is wizard.w, the individual steps wizardsub1.w to 3.w. In the window, I start the underlying .w files persistently. These are set up to suppress-window = yes and have an output parameter that gets filled with the frame handle. This handle is saved in a temp-table in the window and is used to hide/view/move the frame around. I added a counter to the temp-table and two extra buttons for 'next' and 'previous' that use this counter to walk through the screens. A simple FOR-EACH will hide or view the steps. To overcome the problem of having to click the close button multiple times, I let the windows accept a handle to the parent procedure (the main window). A close event is then applied to the parent instead of to the child, so if you close the parent window, it closes at once. It works quite well. Actually, I should have used a dialog instead of a window, but that's a minor thing. Next thing is how to handle updates to the database. Since the steps are individual programs, they need to have a common source for the data if they need to react on each others state. A database will do, but it means that changes by the user cannot be cancelled; if you do something in step 1, it must be recorded in the database otherwise step 2 will not know of it. But it implies that every step you do as a user is immediately recorded in the database. But you might want to undo what you did in the wizard, so I need a better solution. One may be a dataset that is controlled in the window and shared with the children. If anyone is interested, I can throw it on GitHubContinue reading...