I have to assume I have somehow disabled my debugger in a way I cannot see in the interface, as it is skipping breakpoints I set on a regular basis since I upgraded to 5.2.1. No one else seems to be reporting this, so someone point me to how I might have set something wrong? Skip all breakpoints is not selected. See attached. I’m running the method shown with breakpoints in this picture over and over, and it never stops at them.
This is macintosh btw.
More evidence/question in attached screen shot. I put a dialog in my method to prove that it was running, and it is – but the breakpoint is being skipped. I am only a few months into Eclipse, I may totally have a setting wrong. Anyone?
We have experienced this daily for the last few weeks - and only a developer restart seems to fix it!
yes this is logical that it doesnt work
because see on the left…
→ Debugging Engine
If that happens then no break point will be hit ever. Because the debugger has no connection to the client.
You have to hit the launch button again for a connection to be made.
If you have a situation where you see the state switch from connected to terminated where you dont expect it and you can reproduce this, please let me know
This is definitely a 5.2.1 bug – I’ll try to figure out how it happens, but it’s just been plaguing me since I upgraded to 5.2.1. Never happened before that.
there are as far as i can see no changes to the debugger (rhino or the dltk code in eclipse) from 5.2.0 to 5.2.1
It just occurred to me that my smart client launched from developer has been dying lately (since 5.2.1 as well) – meaning that if I leave it idle too long, I come back and it doesn’t respond to anything I click on. I close it (if I can get it to respond to that) and relaunch. I wonder if that’s tied to debugger disconnecting? This symptom is also not something I’m used to. I used to be able to even put my mac to sleep and return to Servoy without client ever disconnecting.
what is the setting that you have in preferences, dynamic languages → debug → response time out?
that should be 0 (never time out)
some how your connection terminates, i will try to improve this by trying to check even better if the connection is killed.
Yes, just checked – Response timeout (sec): 0
ok that is fine then
The you have to monitor when you suddenly see “terminated” in the debug window
at the moment you see that, you have to relaunch the client. That will make the connection again.
If you have a specific place where you see that happening, like you debug and then suddnely it is terminated
that did happen now and then because you show a specific variable that cant be handled. Then a sample would be nice what you debug at that time.
Currently you are on line 1143, but this is a modal dialog that will continue to the next line only after you have clicked on the OK button.
So you should break into the debugger just after this capture, when you click OK. I don’t think there is anything wrong here.
you are hitting a limitation of the mac, breakpoints are ignored on the mac in modal dialogs, else it would lock out everything.
I swear it was never stopping at that breakpoint. At all – even after OK. I was trying everything, setting breakpoints all over the solution – I just screenshotted the one that I needed it to stop at. But I’m not at that mac now so I can’t prove it. Will report back if I see it again, thanks.
You’re not going crazy Ellen. We, too, have seen this behavior with breakpoints in the debugger, and the only way to ‘fix’ it is to re-start Developer. We experienced the debugger working correctly sucessive times within the same session only to have it suddenly stop working (even through the breakpoints were still enabled). I was unaware of the debugger connection termination problem but will watch for it and report back.
jcompagner:
you are hitting a limitation of the mac, breakpoints are ignored on the mac in modal dialogs, else it would lock out everything.
Handy tip for Mac and modal dialogs: keep around a line of code that shows the dialog in the same method that opens the modal dialog. Uncomment it out and comment out the modal call so you can debug. Flip back when you’re done.
var popupName = 'ARCH_P_email__project_lead_initiation'
//turn autosave off
databaseManager.setAutoSave(false)
//new record
forms[popupName].controller.newRecord()
//show pop-up for data entry
application.showFormInDialog(
forms[popupName],
-1,-1,-1,-1,
' ',
false,
false,
'emailProjectLeadInitiation'
)
// forms[popupName].controller.show()
Thanks Kim! I just saw it again, on Windows, and checked for termination in the debugger – no. Also, interestingly – the reason I had set the breakpoint I had set is because it didn’t appear to be running that method. And in fact, it wasn’t. Quitting developer not only made the breakpoint work, but the method started firing again as it always has. Just a bad launch of developer.
about that last thing, now we are mixing up stuff. because if that method didnt run at all (also now with a close of the smart clients solution, so a only a reload there?) then the breakpoint can’t be hit also.
are you using the solution model to alter a form?
Because before the latest release of 5.2.2 when you have altered a form with solution model, the changes you made then in the developer are not reflected in the client
this is fixed for 5.2.2 where we just apply it on the form in the debug smart client even if that is changed (so potentially reverting the thing you changed through the solution model)