When you press the right-most button on the top toolbar (or hit F5) the designer calls #.CPro.Make to run the dialogue in its finished form. This will create the form and all the controls, and then attempt to run the expressions to generate the Runtime and User properties for each control, starting with the form and continuing with each control in the order they appear on the form. It is very likely that some of the expressions with fail on VALUE ERRORs or SYNTAX ERRORs as you may not have set up your test data yet, or you may simply have typed the APL code incorrectly. You will see something like this in the APL session:

      Dbx 'qw'
Designing qw
VALUE ERROR
Exec1[30] 13 'Text'#.CPro.RefreshWith txt
                                     ^

Here I set ‘txt’ as the Text property of a text edit field, but I have not yet created the variable. All I need to do to fix the problem is:

      txt„'Hi'
      …ŒLC

... and the form will appear. If you cannot easily fix the problem with a field, just use …ŒLC+1 to skip the expression and carry on to the next field. If you want to abort the test, just hit … and you will be able to continue in the designer with no damage done.

Setting Causeway to Skip Errors Automatically
By default, CPro does no error-trapping of application code, so that expressions fail as normal and APL waits for you to fix the problem. If you just want to see how a dialogue looks, an easy alternative is to skip errors automatically with:

    #.CPro.debug„0
    Dbx 'qw'
Designing qw
VALUE ERROR                               
Exec1[30] 16 'Text'#.CPro.RefreshWith txt 
                                     ^    
Expression skipped, execution continues ...

All the errors are reported to the session but the finished form will come up on the screen for you to see. You can close it, and fix the errors one by one in the Designer, using the session log as a guide. In the example above, just click on the session (the Designer is non-modal to allow this) and assign a value to txt. Be sure to reset to #.CPro.debug„1 before you do any serious application testing.

Note that you can set the form running with F5, move the running copy to one side, carry on designing and run it again, and so on. This could be a useful way of comparing alternative versions, as well as checking that the dependency mechanism is working correctly..

Running from the APL Session
When testing a dialogue, it is often more convenient to save it from the designer and use #.CPro.Make to run it from the APL session. A handy time-saver is to use function assignment:

      Dbx 'qw'
Designing qw
Dialogue design qw updated
Designer namespace cleared
      cm„#.CPro.Make
      cm qw

You will be able to test out the actions from any of the fields or buttons, and debug the attached APL code without having the screen cluttered with the designer toolbars etc.

One final thing to note is the difference between #.CPro.Make and #.CPro.Call for the finished dialogue.

#.CPro.Make dbx.rec           © returns to APL immediately
result„#.CPro.Call dbx.rec    © waits for the user to end

In general, if a dialogue needs OK/Cancel behaviour, you should #.CPro.Call it and check the result. You will get zero back for Cancel, 1 for OK. If a dialogue can be left open while the user carries on with other tasks, give it a Close button and #.CPro.Make it instead. However any changes it makes will generally go direct to global data, so (short of adding some complex Undo behaviour) there is no way for the user to back out.