Tip needed for initial action in DCL box.

[llorden4]

I've been doing LISP a while and have just started my first DCL box project and things are going pretty good, short of a couple of issues I'm hoping someone can provide a tip on.  The issue I'm running into is that certain action events are triggering by actions to those triggers are not working on the first occurrence, but work every time there-after and sometimes out of sync due to missing the first action.

For example, I started a toggle box with the status checked.  The intent was if the box was checked that default values would be used, user would have to uncheck to override these values and I would then activate a group of edit boxes to allow the user to change the dispalyed values.  The first check would remove the check, but did not change the "is_enabled" state.  All check clicks afterwards did work and the edit boxes toggled every time, but were out of sync with the checkbox.  I was able to work around this by starting my check box unchecked and changed the text so that the box would have to be checked in order to edit.  Everything now works in sync and behaves on the first click as I desire.

I'm now having this 1st action issue with a button.  I'm setting up a button to test for all required edit fields and if they're all present, then I'll activiate the final button to perform the desired task.  This routine also displays a message as to the result of this test for the user so they'll clearly see a value is missing if the button fails to activate.  This message does not appear on the first click, but does with every click thereafter, same with the button activiation if all fields are present, only activates after the 2nd click.

What's the trick I'm missing to get the first activation to function correctly?

[_Tharwat]

Hi ,

If you can describe your aim with that dialog with the actions that you are after to implement or to get , that would be good for all to give you a hand with the more straight reply to the point .

[llorden4]

I'm gathering quite a bit of design data to perform some automatic generation of objects for some lesser experienced drafters.  Basically once all the data is collected, the user will have to hit a Test Values button in which the routine will perform a basic check of values (mainly to ensure they are present) before accepting the final button input to Generate the objects.  Until then the final button is grayed out until all conditions I've selected to monitor are satisfied.  Below is a capture of the window in it's current state, there is much more to go and I'm simply testing as I go along to prove up what is and isn't working before I get too far along and have that mountain of code to pile through to find an issue.

[_Tharwat]

All right , What is the process that you are after with that dilaog ?

Basically you just need to deal with tow functions to deal with with your current problem which they are ( action_tile and mode_tile with the modes of 1 and 0

A hint  , if you want to get sure that all values in edit_boxes are set correctly then you need an action like this to activate a test values button after that.

(action_tile " < override default key > " "(if (eq (get_tile < override default key >) \"1\")
                                              (mapcar 'mode_tile (list \"<floor thikness>\" \"<step thickness>\" \"<step landing>\")'(0 0 0))
                                              (mapcar 'mode_tile (list \"<floor thikness>\" \"<step thickness>\" \"<step landing>\")'(1 1 1)))")

 The above codes says if the key of tile override default is toggled then the first three edit boxes on the left side hand would be ready to receive values otherwise they would be grayed out ( off ) .

[_Tharwat]

Example :

[llorden4]

I think you're missing the point of my post, you're responses are telling me how to supress and un-supress those edit boxes and buttons.  I have already accomplished this task, I dont' have access to video capture while at work else I'd show with a video.  The issue is that it is not activiating "on the first click only".  But I think we can edit your video example to show you what I'm dealing with.  Instead of that checkbox starting unchecked, start it checked (state of 1) for the initial value while keeping the edit boxes supressed.  The first time you clicked the box to uncheck, the boxes won't toggle for me from supressed to unspressed (active).  Every click there-after toggles the suppression.  See if you can duplicate that.

The code I'm currently using for my "generate" button is...

(defun ckVars ()                                                               ;must call saveVars prior to running this sub-routine
  ;--- test for empty or zero fields required for generating
   (if (or (= FWIN 0) (= FLIN 0) (= ROHANG 0))
     (progn                                                                        ;if any are zero or empty then...
       (mode_tile "done" 1)                                                ;turn off generate button
       (princ "\r\nMissing data!"))                                        ;warn user of missing data
     (progn       ;else...
       (mode_tile "done" 0)                                                ;turn on generate button
       (princ "\r\nAll values present, ready to generate.")    ;notify user all values present
     )                                                                                 ;end progn
   )                                                                                   ;end if
)

I like your use of the alert box, will steal that  ;D

I'll try using the mapcar version you showed in your example and see if that has a better result.

[llorden4 · Accepted solution]

Now this is interesting, all I did was change to an alert box (told you I'd steal it) and now it works just fine on the first click.  Sending text to the command bar for user display apparrently has some bug/display issues.  And for sharing purpose, the previous line of code is simply changed to this to function properly.

;--- test entries for OK to complete
(defun ckVars ()                                                                         ;must call saveVars prior to running this sub-routine
  ;--- test for empty or zero fields required for generating
   (if (or (= FWIN 0) (= FLIN 0) (= ROHANG 0))
     (progn                                                                                  ;if any are zero or empty then...
       (mode_tile "done" 1)                                                          ;turn off generate button
       (alert "Missing data!"))                                                        ;warn user of missing data
     (progn       ;else...
       (mode_tile "done" 0)                                                          ;turn on generate button
       (alert "All values present, ready to generate.")                    ;notify user all values present
     )        ;end progn
   )        ;end if
)

[scot-65]

When a dialog is open, one can add text to the command line and a command cannot be started,

however if you do add to the command line, it will only show after the dialog is closed.

As you found out, nesting (or daisy-chaining) another dialog is allowed.

In lieu of using an alert box, insert a text_part just above the buttons and assign it a key="Tex001";, alignment=centered;, but not a label.

In the LISP part of the program you can "set_tile" instead of using an alert.

I have found that using spacer_1; above and below this text_part, the spacing looks uniform.

Change the boxed_row where buttons to just a row.

Are you using a label for the edit_box?

I would suggest converting to a row with a text_part (no label) and a edit_box.

Using fixed_width on the row you can assign a width to the text_part that will cause the edit boxes to align to each other.

Keep in mind that by using labels for any of the tiles, the white space for that tile expands the more characters that are in the label.

When finished tinkering with the text_part widths, simply remove the fixed_width part of the rows.

Finally, incorporate into the LISP part set_tile of these text parts.

Oh, and a spacer_1; at the beginning of a row does good when indenting.

[_Tharwat]

---

@llorden4 wrote:

Now this is interesting, all I did was change to an alert box (told you I'd steal it) and now it works just fine on the first click.  Sending text to the command bar for user display apparrently has some bug/display issues.

---

Haha .. feel free to steal it

Just ask if you in need of any help .

Tharwat

[llorden4]

Thanks for the tips, Scott.  I know I have some fine tuning to appearances to perform once I get everything working.  Playing with the spacer commands is actually next on my list of things to do, to play with the visual display.  Thanks!

[llorden4]

I'm not having any luck at all with playing with the layout.  I've toyed with alignment options which don't appear to have any visable affect at all.  I've tried adding the fixed_width option as "I think" you described and that doesn't appear to have any effect at all either.  I've been visiting AfraLisp for some very good tutorials in DCL layouts and they show some very easy to follow examples of spacer, spacer_0 and spacer_1 commands.  Spacer_0 and spacer_1 keep giving me errors, I believe it's because they don't like being used within a paragraph or concatenation command.  I was able to put in a spacer command, but it too had no affect on layout.

If I understood your suggestion correctly, you commented to add a fixed_width to the text_part so that the edit boxes would align above and below and not be staggered across the screen.  So for this little test, I was playing with just aligning the edit boxes of just the floor width & length input fields.  My DCL for this area currently is...

   : boxed_column {
      label = "Floor Dimensions:";
      fixed_width = true;
      fixed_height = true;
      : paragraph {
 : concatenation {
   : text_part {
      fixed_width = true;
      fixed_height = true;
            label = "Floor Width :";}
          : edit_box {
      fixed_width = true;
      fixed_height = true;
     key = "fl_width_ft";
            edit_limit = 3;}
   : text_part {
      fixed_width = true;
      fixed_height = true;
            label = " ft     ";}
          : edit_box {
      fixed_width = true;
      fixed_height = true;
     key = "fl_width_in";
            edit_limit = 7;}
   : text_part {
     label = " in";}
        }}

      : paragraph {
      fixed_width = true;
      fixed_height = true;
 : concatenation {
   : text_part {
      fixed_width = true;
      fixed_height = true;
             label = "Floor Length :";}
          : edit_box {
      fixed_width = true;
      fixed_height = true;
            key = "fl_length_ft";
            edit_limit = 3;}
   : text_part {
      fixed_width = true;
      fixed_height = true;
            label = " ft     ";}
          : edit_box {
      fixed_width = true;
      fixed_height = true;
            key = "fl_length_in";
            edit_limit = 7;}
   : text_part {
     label = " in";}
       }}
    }

Would you mind appending/commenting on how to achieve this alignment?  Modifications in RED if you don't mind.

*Update*  I replaced the paragraph and cancatenation with the row command, no change in end result or the ability to use the spacer_0 or spacer_1 without introducing an error.

[scot-65 · Accepted solution]

OK, let's try this...

In general, the container for your tiles will have the fixed_width attribute.

The tile itself is to have a width assigned to it. This is what you are missing

(the help facility I have for the text_part tile is incomplete).

For the Button tile, and a few others, add the fixed_width AND a width attribute.

 spacer_0;
 :row {fixed_width=true;
  :spacer {width=4.2;}
  :toggle {key="Tog101"; label="Remind me later.";}
 }
 spacer_0;

text_part by itself in a row does not require a width. However once you assign a fixed_width to the row,

then the text_part will require a width, otherwise the tile is completely collapsed.

:row {alignment=centered;

 :text_part {key="Tex101";}

}//row

:row {alignment=centered; fixed_width=true;

 :text_part {key="Tex102"; width=20.0;}

}//row

If you assign a fixed width to a button, the button is minimized to the width of the text inside the button plus a margin.

If you do not assign a fixed_width to the button, the button expands the entire width of the row (if by itself in the row

and the row does not have the fixed_width attribute).

From this hint, one can "nudge" the width of the smallest button using width to be the same size as the largest button.

Now all buttons can be the same size as the widest one.

Start by creating simple rows for each button. Trial and error to make smallest button the same size as the largest.

From there, make all button the same width. Finally, combine into one row and add a spacer in between.

:row {fixed_width=true; alignment=centered;

 :button {key="But101"; label="101"; fixed_width=true; width=18.4;}

 :spacer {width=2.3;}

 :button {key="But102"; label="10001"; fixed_width=true; width=18.4;}

}//row

Using the height attribute is limited. I use this only to nudge the toggle tile down to be more in line with an edit_box tile

when these two tiles are in a row container.

:spacer {width=0.0;} believe it or not is a tad larger than spacer_0; but much smaller than spacer_1; I use this one quite frequently.

I have not used the tiles paragraph or concatenation in any of my developed dialogs.

Hope this helps.

[llorden4]

Thanks, very helpful indeed.  I did have to play with it quite a bit to figure out just the right values, but I was able to make positive headway.  The only area I couldn't affect the way I wanted was the distance between the text_part and the edit_box; neither alignment or spacer had a positive effect in my attempts.  Defining width's for the text_part would never get smaller, I could only make them longer and thus take up more space.  Alignment (left/right) just threw off the horizontal alignment....  weird!  At any rate, I'm pretty satisified with the current look.  Thanks to you gentlemen for your patience and expertise, the previous DCL box now looks like...

For anyone following the code changes, they are...

   : boxed_column {
     fixed_width = true;
      label = "Floor Dimensions:";
      : row {
   : text_part {
            label = "Floor Width :";}
          : spacer {width = 2;}
          : edit_box {
     key = "fl_width_ft";
            edit_limit = 3;}
   : text_part {
            label = " ft     ";}
          : edit_box {
     key = "fl_width_in";
            edit_limit = 7;}
          : spacer {width = 0;}
   : text_part {
     label = " in";}
        }

      : row {
   : text_part {
            label = "Floor Length :";}
          : spacer {width = 1;}
          : edit_box {
            key = "fl_length_ft";
            edit_limit = 3;}
   : text_part {
            label = " ft     ";}
          : edit_box {
            key = "fl_length_in";
            edit_limit = 7;}
          : spacer {width = 0;}
   : text_part {
     label = " in";}
       }
    }

I can now move on with confidence and add the remaining 50 input boxes and 750,000 lines of code.

[scot-65]

If you assign a value (label) to the text_part there will be a white space added to the end of that tile.

Suggest trying the following [exactly as written]:

 :text_part {key="Tex001"; width=6.0;}

Now in your LISP part, in your set tile area, do this:

 (set_tile "Tex001" "Floor Thickness (in.):")

Now it will be compact. The text string will truncate if the width value is set too small.

Again, you forgot to assign a width to the text_part...

Oh, in lieu of having the user possibly entering incorrect information in the edit boxes, try popup_list.

Your program looks as if standard measurements are the norm.

The first item in the list is position 0. You can use that as a check to see if the information

has been set. "Choose One" or "None Selected" are possible values for position 0.

The tile returns a string when you make a get_tile call. Convert to integer will help when you

run the value thru a COND statement.

Back in the LISP set section:

 (start_list)(mapcar 'add_list "MyList")(end_list)

and follow up by setting the position of the tile to 0:

 (set_tile "Pop101" "0")

 (mapcar 'add_list (list "Choose One" " 3.5\"" " 3.0\"" " 2.5\"" " 2.0\"" " 1.5\"" " 1.0\"" " 0.5\""))

As an alternate to building the list inside the LISP file, you can do that in the DCL file.

In the DCL file the list is quoted as a whole and separated by new line symbol.

 list="Choose One\n 3.5\n 3.0\n 2.5\n 2.0\n 1.5\n 1.0\n 0.5";

Add spaces and escape the inch as needed.

 list="Choose One\n     3.5\"\n     3.0\"\n     2.5\"";

Will you take my suggestion by adding a "comment" line above the buttons?

The comment line is initially blank and will flash a value when the appropriate button is

pressed - I'm trying to ween you away from disabling the buttons along the bottom.

I'm also trying to eliminate extra steps to complete the task (closing the alert box).

Does your program mode_tile (=2) to the incomplete tile?

Maybe place a flag in the program that if the button is pressed once, the incomplete

message is displayed, and if the button is pressed a second time (without any other action),

then show the alert box that there is a bad connection between the keyboard and chair...???