Hi Roy,

Not completely sure how you mean that but you can create Tasks without code that upon a click will activate a detail screen (Process flow). With this you could create a sort of wizard.

Or do you mean something else?

I noticed that when I open a detail document and add a new row I can edit its content. However it isn't possible (or I don't know how) to add a task that is available when editing this content. I first have to save this information before the task becomes active.

This means that I need to first save this information before I can activate the task. It also means that I can't hide the confirm and cancel buttons and always have the navigation and refresh buttons.

In the three mentioned screens used on deploying this combination of editability and enabled buttons seems to be possible, so I want to know how this is done so that I can use these ideas to apply them here.

That is indeed how it works, task visibility is part of the Context procedure which only gets executed upon selecting a row. Attaching tasks to the GUI buttons is not possible but there's an idea posted for it:

For now it is possible to have something very clever.

1. Have a task to open the wizard document, but also to insert a row into the wizard.
2. Then in combination with auto-edit form and autosave you can use always visible tasks that check if the fields in the wizard tab are filled.
   1. If not, give an error for example

It does require that the wizards does not have standard mandatory field except for an identity. With the Laylout procedure, you can make wizard fields mandatory. 

Hope this helps!

Hi Mark,

I see that a subject can have Default editable & Auto-save form

Not sure what you mean by “always visible tasks"?

Currently I have (in the process flow):

• One start task without content;
• One Open document for the view;
• One Add row for the view.

Result of starting is

Also not sure how this “Auto-save form” works. When will it trigger the save-procedure when the confirm-button is hidden?

And of course very curious how you achieved this in the deployment-process?

Hi Roy,

I made a little example that shows a sort of wizard:

With always visible tasks I meant that the Task does not get hidden by the Layout. The naming I used is confusing, sorry.

Also not sure how this “Auto-save form” works. When will it trigger the save-procedure when the confirm-button is hidden?

Auto-save form will save the information in the form when you leave the form. When you click a task, that counts as leaving the form. This is why the example works. The information filled in gets saved upon clicking the task. Note that I hide all form buttons.

The deployment process, or Creation, is a set of Custom screens specially designed for the Software Factory. 

So how do I recreate this?

How to:

• Have a table with at least an identity column and a current_step column (int). This is important as it will tell on which screen the user is. 
• Give that table x-amount of self-references without reference columns, one for every step in your wizard. This example will have 5 steps (Generate, Validate, Execute, Deploy, Done):

Make sure none of the fields are mandatory, otherwise this might mess up the initial insert of the wizard entry.

• The container can only show one record so we need to make sure the correct record is selected. Use a prefilter to accomplish this. In this example I have a prefilter that only shows entries with a current_step lower than 100; which I will make sure is always one record.
• For every step, create a variant with own translation (and icon if desired). Have the details of the container look to the correct step-variant.

• These variants should have the following settings on:

  

   

• For the container containing all steps, make a screentype that has a Detail tabpage and a task bar in the desired location.

• For wizards, it's most handy to use a Form_only screentype for every step.
• Assign the form_only to the variants

Halfway!

 

Next up is making sure the variants are showing the correct fields in the form.

• Set up which fields should be visible, read only or hidden for each step. 

Next up is setting up a Task that will guide the user through the steps. 

• Make it none Task logic type as it does not need to do anything itself.
• Attach it to the Container table, Not the variant(s), with the ID and the current_step connected. Let the task be disabled in empty subject if desired.

The Task needs to start a Process flow. That process flow will decide in the Process procedure of the Execute table task which detail to Activate. Based on the current_step, we know what step is next-up.

• Create a process flow that looks like the following. Notice that step 1 is not included as we start on step 1. Also notice the Close document to close the container when the Task is pressed at the last step.

• Enable Process procedure on Execute task next_button
• Have the ID and the current_step as Process variables and assign the to the Output of the Execute task process action. Now these will give the value back to the process flow; which we need.

Let's do some code writing!

• Create a Control procedure - Processes - and assign it to the Execute task process action. (A template will be created if not already present)
• In Result, notice all variables you have and write something like this:

if @current_step = 1
begin
    update c
       set c.current_step = c.current_step+1
      from deployment_container c
     where c.deployment_id = @deployment_id
       and c.current_step  = @current_step

    select @execute_tab_task_deployment_container_activate_detail_deployment_validate = 1
end
else if @current_step = 2
begin
    update c
       set c.current_step = c.current_step+1
      from deployment_container c
     where c.deployment_id = @deployment_id
       and c.current_step  = @current_step

    select @execute_tab_task_deployment_container_activate_detail_deployment_execute  = 1
end
else if @current_step = 3
begin
    update c
       set c.current_step = c.current_step+1
      from deployment_container c
     where c.deployment_id = @deployment_id
       and c.current_step  = @current_step

    select @execute_tab_task_deployment_container_activate_detail_deployment_sync     = 1
end
else if @current_step = 4
begin
    update c
       set c.current_step = c.current_step+1
      from deployment_container c
     where c.deployment_id = @deployment_id
       and c.current_step  = @current_step

    select @execute_tab_task_deployment_container_activate_detail_deployment_done     = 1
end
else if @current_step = 5
begin
    update c
       set c.current_step = 100
      from deployment_container c
     where c.deployment_id = @deployment_id
       and c.current_step  = @current_step

    select @execute_tab_task_deployment_container_close_document_deployment_container = 1
end

Using increments of 1, and setting the current_step to 100 to determine if the wizard is finished.

Now we are able to click through the Container, but we are missing one thing. How do we get an entry into the Container to start with?

You could have a task inside the Container entering an entry into the Container table, but this example will show how we can use a Task as menu item to insert the Container entry.

• This task will have a template. Also put it in the desired spot of your menu. 
• The task will insert a new record into the Container, but only if no other entry is currently being worked on. We can see that by looking at the current_step value. 

if not exists(select 1
                from deployment_container c
               where current_step < 100) 
begin 
    insert deployment_container (current_step)
    values (1)
end

• Also, this task need to open the Container so head over to Process flows and create one. Psst, the document can be opened floating if you desire 

So what we have now is a Task on the Menu that will insert an entry into the Container and open the Container. The Container will show its steps and a Task is available to navigate through the different steps. Do note that throughout this example you can add alot more handy functionality like Messages, Layout and Context procedures and much more.

Optional:

• Set up a Layout procedure to make fields mandatory when they are. Use the current_step column to know on which screen the user is. 
• Set up a Context procedure to disable details when they shouldn't be accessible for the user
• Give a message to the user upon clicking the Next button if not everything has a value
• Use Conditional layout to make fields more appearent

Final result:

Hope this is enough information