Window.activate not allowing method to finish

I am having a problem in the debugger (XOJO 2017 1.1) on a Mac with a method that is somehow activating Activate.
The problem is Activate is not returning to the method.
I’m not too sure what else to include, but it seems to happen when a textarea has data changed.
It somehow happens when I use an arrow key.

Is the Window set to Implicit Instance? That’ll make the Window Activate any time you touch anything on it.

I’m sure it is.
My problem is mostly it doesn’t return to the method that caused activation

[Totally Guessing] Is it a Modal window?

nope. Just to be clear, activate doesn’t happen elsewhere.
I can’t stick a breakpoint in there without having it fire so I can’t test it.
I also know when it happens because TextChange isn’t called. Inside textChange is a method to set the font size.

I’d be curious to see why it’s not completing the method that had called the change.
If you’re up for sharing the project feel free to PM or email me.

What is causing the ACTIVATE to “fire”… it should be only by virtue of “showing” the window, or addressing an attribute of the window…
Same goes for Textchange … is the textfield you are “changing” located on the same window?

Based on the information provided…

  • you are doing “something” that “activates” Window X… what is that “something”?
  • you say “textchange” event never fires… but is the textfield on Window X or Window Y?

if on WINDOW Y you had code similar to this

msgbox "Hi!"

this would do the following

  • Activate Window X because you referenced an attribute of the window (ie. myText)
  • set the value of mytext to “STUFF”
  • fire the TEXTCHANGE event on WINDOW_X for the “myText” control
  • display “HI!” in a message box [which may cause window_X activate to be called again when msgbox closes]

[quote=351264:@Dave S]What is causing the ACTIVATE to “fire”… it should be only by virtue of “showing” the window, or addressing an attribute of the window…
If the window is implicit instance and you touch anything on the window, it causes the window to Activate.

I’m not sure what you’re getting at, Dave. Touching anything on the window causes it to activate. The only thing I can think of that wouldn’t cause an Activate is accessing a Constant. Is there anything I’m missing?

Edit: formatting

“addressing an attribute of the window” = “touching anything”

Ah, I see, just terminology :slight_smile:

Thanks for the input. I’ll look at attributes. I did locate the line of code that sets off Activate.
It is in the APP in a routine for setting the font size. It doesn’t change the shape of anything, just the size and shape of text and latter moves the scroll up.
This piece of code is accessed hundreds of times, so I’m also wondering if Activate is on a delay (Just asking),

I found the problem and I’m confused that something else didn’t happen. The sellength for a textarea became -1 and instead of an exception being thrown, activate was fired

There is no “clamping” done on Sellength… by this I mean it can be ANY value positive or negative… but only affects the textfield if the value between 0 and length of text

So what is activate-ing. I am rewriting this and I know it’s bad coding on my part but I’m confused about the results. I am mostly confused about activate not returning to the routine. What would stop this from happening?

something is changing/touching/referencing the window that is being activated
it this textfield you keep referring to ON THAT WINDOW? if so, then that is the trigger

how do you “know” it is not returning, when in fact you don’t seem to know WHY it is triggering “activate”

Something besides that text is being added or that text in the sellength is for instance being highlighted. I think it has to do with the length being -1 because after that things aren’t respected. If I figure it out I’ll post here

seeing as you don’t wish to post snippets of the code, we can’t keep guessing… so good luck

Sorry. Doing this from my mobile phone. I also have, of course, too many lines that look alike but this is The one.
Tcont.selstart = = prime1a+1
Tcont.sellength = loclf - tcont.selstart

Tcont is the texarea
Loclf is location of the linefeed and is 0 because there is none (result of an instr of the text) .
Prime1a is the location of a start of being highlighted. Not the end.
So sellength is here a negative number. Otherwise it is zero from an instr test