Cannot Confirm cancel anymore

questions
1

A few days ago, I discovered that when aborting the changes in the forms no longer gives me the choice to confirm the cancellation or not. This happens with all the forms in all the apps in the solution. As far as I can see, the code generated for the forms is correct. (SELF.CancelAction = Cancel:Cancel+Cancel:Query).

If I change Confirm cancel to Offer to save changes in the forms extensions, this gives me the right message.

Anyone have any idea, or tips for troubleshooting this?

2

I like the debugger and debugview, sometimes the debugger is useful for stepping into the built in ABC classes and debugview for my own code.

3

is there a global templete setting for this? Sounds like a default has changed

4

This is obviously a global issue in that it applies to all the Forms in all the apps. But I don’t think this is a template issue. I have not changed the Form template, and in the Forms the self.CancelAction is set to Cancel:Cancel+Cancel:Query, which should give me the choice of saving changes or not.

5

I think this Cancel:Cancel + Cancel:Query
Should be Cancel:SAVE + Cancel:Query ? (wrong)

In TakeCloseEvent() unless CancelAction has the Cancel:SAVE (=1) bit neither of the questions is asked (wrong).

Edit 3/30: As Rick noted below the prior sentence is wrong. When CancelAction = Cancel + Query the Form shows a Confirm Cancel Message ‘Are you sure you want to cancel?’.

WindowManager.TakeCloseEvent PROCEDURE
  CODE
  IF SELF.Response <> RequestCompleted AND ~SELF.Primary &= NULL
     IF SELF.CancelAction <> Cancel:Cancel AND ( SELF.Request = InsertRecord OR SELF.Request = ChangeRecord )
        IF ~SELF.Primary.Me.EqualBuffer(SELF.Saved)
           IF BAND(SELF.CancelAction,Cancel:Save)   <===== Must have Cancel:Save
             IF BAND(SELF.CancelAction,Cancel:Query)
                CASE     SELF.Errors.Message(Msg:SaveRecord,Button:Yes+Button:No+Button:Cancel,Button:Cancel)
                    OF Button:Yes
                      POST(Event:Accepted,SELF.OKControl)
                      RETURN Level:Notify
                    OF BUTTON:Cancel
                      SELF.OnCloseEventCancelled()
                      RETURN Level:Notify
                    END
                  ELSE
                    POST(Event:Accepted,SELF.OKControl)
                    RETURN Level:Notify
                  END
                ELSE
                  IF SELF.Errors.Throw(Msg:ConfirmCancel) = Level:Cancel
                    SELF.OnCloseEventCancelled()
                    RETURN Level:Notify
                  END
                END

AbWindow.INC has these equates where you can see Cancel:Cancel = Zero

  ITEMIZE,PRE(Cancel)
Cancel  EQUATE(0)                 !  Cancel:Cancel 
Save    EQUATE(1)                 !  Cancel:Save
Query   EQUATE(2)   ! Bitwise-OR ed
  END
6

I believe Cancel:Cancel+Cancel:Query, which is really just Cancel:Query, does not prompt you to save if there have been changes made. It will prompt you to cancel the close so you can go back to editing vs. just losing your changes.
Cancel:Save - without Cancel:Query will simple save any changes without prompting the user when the form is closed without saving.
Cancel:Save with Cancel:Query will prompt the user to SAVE their changes when the window is closed without saving.

Now, what’s happening to @tgulden is still in question. I’d just run it through the debugger and see where it isn’t going to the code you expect and see why.

1 Like
7

I agree the code shows Cancel:Cancel+Cancel:Query does a Confirm Cancel message … when the record has changed (i.e. EqualBuffer() = False) and Response <> Completed.

But if SELF.Saved got accidentally reset to the current record buffer then EqualBuffer()=True and that would cause no message.

image
image924×568 30.9 KB

Instead of using the debugger an alternative is to put some code in the local derived TakeCloseEvent() before the Self.Parent() call and check some values. Some of it may be Private making it impossible to access without removing Private in ABWindow.Inc … which you can easily undo.

8

I have to do this to the abfile.inc for a template of mine.autoinc

9

The debugger did not help me, but I changed ABWINDOW.clw to

ABWINDOW
ABWINDOW2762×1558 499 KB

and this works. So the question is why Throw does not anymore. This is only related to this project. New Apps work with Throw

10

I can only asume that maybe a template has changed the settings for some reason.

11

If there is a template issue, then new apps will also have this problem. But they don’t.

12

Apart from the form template, I have 2 templates in my registry that set the CancelAction.

  1. The “in the box” - CleanCloseDown Global extension template. and
  2. The WinEvent global extension, “CloseDown Event forces close Windows” option.

Both respond to an event:CloseDown in system, which then triggers this clean-close window behaviour.

I recommend if this doesn’t help then come to the User Group webinar on Wednesdat (www.clarionlive.com) and we can look at your generated code to see where the CancelAction is being set.

Cheers
Bruce

13

I was looking at the Throw method in the abError.clw which goes to the SetErrors method and noticed there is a reference to the ErrorStatusClass in abError.inc.
LINK('ABERROR.CLW',_ABCLinkMode_),DLL(_ABCDllMode_)

So a couple things that could be checked is the Project Defines, ie ABCLinkMode and ABCDllMode which depends on how you are compiling the app, ie multi dll or not, but I would have expected more problems if these were right.

The other thing is
V LIKE(ErrorStatusGroup),PRIVATE

Is this something affecting all files and forms or just some? If some, are their names longer than 254 characters? I’ve never used a filename thats longer than 254 characters so I dont know how clarion would handle this.

ErrorStatusGroup              GROUP,TYPE
FieldName                       CSTRING(MessageMaxlen)   ! name of field that produced the error
FileName                        CSTRING(MessageMaxlen)   ! name of file that produced the error
KeyName                         CSTRING(MessageMaxlen)   ! name of key that produced the error
MessageText                     CSTRING(MessageMaxlen)   ! message text
SaveErrorFile                   CSTRING(255)             ! name of the file for which an error was posted
SaveError                       CSTRING(255)             ! Clarion error message
SaveErrorCode                   LONG                     ! Clarion error code
SaveFileError                   CSTRING(255)             ! File system's error message
SaveFileErrorCode               CSTRING(255)             ! File system's error code
ErrorBuffer                     LIKE(ErrorEntryGroup)
PrevErrorID                     UNSIGNED
                              END

This is where stepping through the abc classes in the debugger can shed some light.

14

This is a multi Dll and it affects all the files and all the forms in the project. And the file names is no more the 8 characters.

I have made a new app in the same directory using the same dictionary, but not linked to the project, and there are no problems.

So there is nothing wrong with the templates or the .inc files. This is an old project that has worked for years. I guess it must be something in the data dll or in the project setup.

If I don’t find out, I will try to join the User Group webinar on Wednesday.

15

This sounds like one of the flags was changed by SV and has not been updated in all the modules of the app. There was a change reported when going to C11.1 and they said re-compile all exes and dlls.

Try a “Clean” in the IDE.

Also check for local values that do not use the symbol names, i.e, they use numbers or something hand entered. Those would need to be edited to use the new value, or the symbol.

Whatever they changed, it is not good to re-number symbols unless there is not other way. Better to add new symbols to the end, so it causes less havoc.