I used vb6.6 application and my form unload method not fired when I click ok button. It came from One of my .ocx file control but other cancel button fired because that's not an ocx control button
when in debug mode, events don't fire in the order they normally do. My suggestion is that you use the Debug.Print to send tracking msgs to the immediate window rather than trying to 'step debug' thru that event. Put a break in your code just before your first ( of potentially many ) Debug.Print statements ... then when the debugger stops there, switch out of debug mode and let the code run free, using the messages in the immediate window to tell you what you would have gathered visually while stepping thru the code. Have done this many times, successfully. It takes some patience to get it to work, but once mastered, it works every time.
Related
I'm facing an issue with inputs loosing focus. The issue is like this:
I send an AJAX request to load a form, when loaded I display it with in a modal.
Now if I click on any of the inputs it gains focus and blurs immediately, so I need to click it again (and this time it stays focused).
I need a tool that traces the event flow and dispatching in Firebug's console (or some similar tool), so that I can detect the culprit for this odd behavior and fix it.
I have tried Eventbug and FireQuery; but I haven't be able to find the code that causes this.
You may go to scripts panel of Firebug, then hover your mouse over the input, then click ALTCTRLB from the keyboard to activate "Break on next", then click the input, and it should hit a breakpoint in the onclick handler of the input, then you can go through the code to find potential calls that cause blur (provided that you don't do any aggressive polling via setInterval/setTimeout in your javascript for some reason, or the framework you use doesn't; then it'll likely pause in that code).
You may also want to execute some code at the very beginning of the page to override the addEventListener method so that you hijack it: log any calls to it, and forward execution to the original function; see slides 13-14 of my presentation (I do it in Greasemonkey, but it's not relevant here; just make sure this is executed at the very beginning of the page).
I'm trying to use OllyDbg's "Execute Till User Code" feature (which is essential for me) but it never works.
I first tried it on a program which called MessageBoxA. When it called it I paused the program in the debugger and issued OllyDbg to execute till user code, but the program was still paused and completely frozen. I couldn't even click the MessageBox's OK button, or even make it continue from OllyDbg. When I tried too hard to make it continue it just crashed.
So I decided to write an application in NASM (to have complete control) and tried it there. The MessageBoxA popped, I paused, executed till user code, I could press the OK button this time, but OllyDbg didn't pause the program once I did. The program just executed as if nothing happened.
Why doesn't it work and what can I do to solve it?
OllyDbg 1.10 (No Plugins)
Windows 7 Ultimate SP1 64-bit
Update:
I've tried to use OllyDbg 2.0 but the Execute till user code button is completely disabled for some reason.
I ran into the same issue while following Lena's tutorial #4 and I think I've figured it out. When I press Alt+F9 to "Execute Until User Code," I notice that all but one thread in the Threads window (Alt+T) have the suspend flag set. Evidently, Alt+F9 only resumes one thread. Fortunately, OllyDbg has the ability to manually resume the other threads by right clicking on them and selecting "Resume" (or by using the + key). For me, this was sufficient both to unfreeze the dialog and to get OllyDbg to pause immediately after the call to MessageBoxA.
The setup
I have an MVC application that's making AJAX requests into my controller. The javascript is making more than one such request.
On my controller that gets called, I have a break point.
The annoyance
When I want to debug that controller action method, I hit my breakpoint, press F10 to continue on, but then the second request comes in and I hit the breakpoint again! I've now got two requests flowing through my code, and pressing F10 steps between the two, making the debugging nearly impossible as the current line jumps up and down, between files, etc without any consistent flow as it's tracking more than one request in the current debugging session!
My question
Can I tell a single request to just... go away... without affecting the other one? I've tried F5ing just one request, but that makes both continue, not just the current one.
You could disable the breakpoint immediately after its first hit (Ctrl-F9, or right click on the breakpoint and click disable - this is different from removing the breakpoint).
You can also "Freeze" a thread in the threads window (right click on the thread and click "Freeze" - use "Thaw" to reverse this).
I've followed the Google app script tutorial here which is a very simple script with two functions. showDialog (which presents a dialog box with a text field and submit button ) and respondToSubmit(e) which handles the submit button and adds the entered data to the spreadsheet.
It works fine.
What doesn't seem to work is the debugger on the callback. So I place a breakpoint in both functons and start the showDialog function. The debugger kicks in and stops execution at the breakpoint. I click continue so I can interact with the newly opened dialog box. However when I click the submit button the debugger does not start again. The respondtoSubmit(e) function is executed. The debugger just does not stop on the breakpoint(s).
Is there a problem with debugging callbacks like this or can you only debug one function at a time?
For reference Utilities.jsonStringify(e) is depricated, use JSON.stringify() and JSON.parse() instead.
As of right now, the debugger has some unexpected behaviours. Mostly, it seems to only respect breakpoints during calls from the script editor, so to debug your event handler you must call it from the debugger, not the UI. If you need to peek into variables such as the event object passed to the function, for example, try adding this line to your handler where you'd normally put a breakpoint:
Logger.log(Utilities.jsonStringify(e));
Then view the log from the script editor after execution.
It seems to me that the Logger does not work either, unless run from the script editor. I did manage Browser.msgbox(Utilities.jsonStringify(e)) which had brought the (expected) result:
{"parameter":{"clientY":"45","clientX":"37","eventType":"click","ctrl":"false","meta":"false","source":"u12053277590","button":"1","alt":"false","myTextBox":"babi","screenY":"381","screenX":"598","shift":"false","y":"13","x":"33"}}
I've got a long-running macro, in which I write periodic messages to Output just so that the user know somethings happening. The problem is that the output doesn't get shown until the macro has finished (unless you have the Continue Waiting? dialog box open, strangely enough).
Is there anyway to 'flush' the event queue?
If you reference Windows Forms you can access Application.DoEvents as normal.
I have the main IDE responding to windows updates and closes in real time while the macro is still running with only
DTE.SuppressUI = False
Threading.Thread.Sleep(5000)
As such I suggest using a standard DoEvents & Sleep(55) loop for a 250 milliseconds or so when you want to ensure the UI is updated should do the trick, along with the SuppressUI=False.