IDE: list of not yet defined available handlers

[Cairoo]

Dear LiveCode Forums,

When editing a card's script, there's a list of handlers and functions in the left pane. The handlers and functions that are already defined, appear on top. Below that is a list of messages handlers that are not yet defined, but available in case you would like to define it. I just wonder why certain handlers are removed from the bottom list when certain other handlers are defined, e.g.
the openCard handler is removed from the bottom list when the preOpenCard handler is defined, and the openStack handler is removed from the bottom list as soon as the preOpenStack handler is defined. I think it's an IDE bug, but perhaps someone here can explain why maybe it isn't a bug?

Thanks in advance.

Gerrie

[jmburnod]

Hi Gerrie,

the openCard handler is removed from the bottom list when the preOpenCard handler is defined

I confirm this strange stuff (LC 9.6.6

Best regards
Jean-Marc

[bn]

Hi Gerry,

If you want to report this as a bug then you could add that the problem seems to be in stack "revsehandlerlistbehavior" starting at line 135 in handler "update"

Code: Select all

# Description
#   Called when the group might need to be updated. Updates the handler list. Also resizes the group.
command update
   lock screen
   local tHandlers
   call "revSEGetHandlerList" to the cCaller of me
   put the result into tHandlers
   
   local tDefaultHandlers, tIndex
   if sePrefGet("editor,showDefaultHandlers") then
      put revSEDefaultHandlers() into tDefaultHandlers
   end if
   set the wholematches to true -- this is originally set to false, setting it to true avoids openCard/preOpenCard mixup
   

The last line "set the wholematches to true is originally set to false, setting it to true avoids openCard/preOpenCard mixup

Kind regards
Bernd

[Klaus]

The last line "set the wholematches to true is originally set to false, setting it to true avoids openCard/preOpenCard mixup

I guessed, how embarrassing for LC!

[bn]

The last line "set the wholematches to true is originally set to false, setting it to true avoids openCard/preOpenCard mixup

I guessed, how embarrassing for LC!

I wonder why they have set "wholeMatches" explicitly to false in the first place. I could not think of any reason but still there must be one.
Probably the author originally set "wholeMatches" to true and found a problem and decided it was easier to set it to false than to take the line out.

And speaking of "wholeMatches" and embarrassing: I think that more than half of the problems of the Project Browser are missing "wholeMatches"

https://quality.livecode.com/show_bug.cgi?id=23352

Kind regards
Bernd

[Klaus]

Ouch!

P.S.
@ Bernd:
Einmal mit Profis arbeiten, wa!?

[Cairoo]

I have filed a bug report. Here's the link:

https://quality.livecode.com/show_bug.cgi?id=23616

Hi Gerry,

If you want to report this as a bug then you could add that the problem seems to be in stack "revsehandlerlistbehavior" starting at line 135 in handler "update"

I've included your comment below the initial bug report.

[bn]

Hi Gerry,

thanks for reporting this bug.

Kind regards
Bernd