Page 2 of 2

Re: Active Window

PostPosted: Mon Aug 11, 2014 7:43 pm
by schmutly
OK...very Odd. If i comment out the nphook stuff the error , MODULE, goes away.
To make things VERY clear i created a camtasia video:

Any thoughts? It scares me as the module error Dave mentioned when i first
posted it a year+ ago hadn't seen it before..i wonder if a DLL is being corrupted
or deleted ..don't know.Thoughts? (after watching video in action)

PS: if you pause and examine the enter-page and subroutine that's all the code,
there's if you try it yourself it will WORK...and it DIDN'T give this error in
the beginning of the night when 1st did it so VERY ODD....actually, in case my
memory is corrupted i will restart the PC (no didn't do that..) but if it fixes it
will post back here ..if not i wont update this post (doing it now...)


Re: Active Window

PostPosted: Mon Aug 11, 2014 8:20 pm
by Tony Kroos
I compiled mouseEvents demo app to check module error stuff, and ran across another. Try clicking buttons and dragging listbox slider for some time (10-20sec), then hook stops processing messages and show this error when I close demo app - "Invalid hook handle".

Re: Active Window

PostPosted: Mon Aug 11, 2014 8:45 pm
by schmutly
Hi Tony,
just updating first...i rebooted PC and it possibly was a memory my compiled published mouseman worked
as far as opening the problems so far.
I will change it back to opening the ctrl + o which i don't see a problem this is the STANDARD shortcut keys
for most programs (office,notepad,NB etc..) and having the middle mouse with this command will be great for me as
i Never use the middle mouse at all .
dec wrote:Hello,

You can try by stop/start the hook in the event subroutine. Something like:

Code: Select all

  Stop the hook here

  Do whatever you wanted here

  Start the hook again if you need


I think the ABOVE code from David is what i needed to add for the reasons he does his demo have
that stop|start in it as well, and if NOT i wonder if that will fix it? Will try it too.
BUT.....glad the module error gone :) , but DON'T know why it appeared... :(

Ok..i got that error too Tony, but i think its because i didnt compile it and try.
So before i did that i changed the demo sub.Rout. to:

.Because WM_MOUSEMOVE ocurr doooozens of times, and for this sample is not interesting
IfEx "[Event] <> [#34][#34] AND [Event] <> WM_MOUSEMOVE"
npHookMouseStop ""
ListBoxAddItem "ListBox1" "0" "Event: [Event] - X : [XPos] - Y : [YPos] - Data: [Data]"
npHookMouseStart ""

And compiled and ran it and that error, "Invalid hook handle", which appeared only inside NB F9 run
and on close button...the error diidnt appear on compiled....for me anyway.

Also...i keep forgetting Davids advice here in his plugins:
But all the NeoPlugins also incorporate an advanced way to deal with possible action errors.
You can define a subroutine named OnNeoPluginActionError in order to be executed when some action
error are found and you can use this variables inside:
[LastError] The last action error message. [PluginName] Store the plugin name which cause the error.

so will use the [PluginName] next time if i get it, may help narrow things down :P

Re: Active Window

PostPosted: Tue Aug 12, 2014 1:18 am
by schmutly
Got it working .
Now it sits in background...and i can open ANY program
which uses CTRL + o to open and it works..
The The PUB if anyone want to see...
Thanks again folks,

Re: Active Window

PostPosted: Tue Aug 12, 2014 4:08 am
by dec

The npHook plugin is a bit special, since they execute LOTS of events that we cannot use for certain things. Taking a look at the sample, certainly I also get the problem described above, however, if we modify the sample in order to DO NOT inform about EVERY event of the plugin (doing for sample purposes, but probably not a good idea in general) we can get the "invalid handle error". Not only this, but, the hook do not work correctly.

I think this is a combination of the previously I say: the very very LOTS of events that the plugin fired, in combination with the nature of a NeoBook plugin and a NeoBook publication itself. Certainly EVERY event set certain NeoBook variables and, most important, execute certain subroutine. The variables part do not cause problems (at least in my tests) but the subroutine executions (LOTS of subroutines executions) yes. It's like they do not end with a subroutine execution when another events are fired and therefore require to execute the subroutine over and over again.

I say before the hook event is not the very best place to shown an user dialog. Well, also appear not the best place to interact with a visual control, like the sample ListBox control. Certainly the number of events and subroutine executions can cause problems, because in the sample case every event and subroutine execution update the ListBox control. I want to update the sample in order to do not inform about every event in such way.

Re: Active Window

PostPosted: Tue Aug 12, 2014 5:04 am
by schmutly
....I say before the hook event is not the very best place to shown an user dialog....
...therefore require to execute the subroutine over and over again....

Hi David.
So.........what i THINK your saying is its not a good idea to have this running ALL the time as the mouse events are being checked ALL the time...CORRECT?
Thats OK...because i put a DISABLE button on my little JOB..and i only RUN it (the APP) when i am HEAVY using Photoshop or NeoBook. fact..if you LOOK at my pub i uploaded it seems to not affect anything at ALL..maybe might cause unusual things im not familiar with to windows in the background?

OH....that would be great if there was SOMEWAY to just monitor ONLY a middle Mouse button and not the left or right BUTTONS....that would help a lot...
Is this easy or going to be possible? I'm surprised that there's actions in Neobook and other plugins for Left and RIGHT...but that's why i grabbed this plugin as it
appealed to me being able to USE the middle mouse.
I hope there is a solution to only monitor JUST middle mouse button if its not too hard...but at present, at least its working without any "noticeable" side effects...YET!! :|

Thanks for the explaining..and let me know if there's a solution about the other 2 buttons.If not i can live with this and putting the STOP/START for the hook in the Sub Routine
seem to do the job.

I added a toggle enable/disable button in the taskbar app when i want to turn it off and use my Middle-button for clicking in web browser etc i can...and re-enable it at
anytime when in an app that i need (Photoshop especially as opening tons of images to edit all the time and is a PAIN IN THE @#@$@#$ going UP to open but so much
easier now just using middle-mouse to open...after 1.5hrs in adverse affects at all EVEN clicking middle on windows or anywhere there is not even a CTRL + o option)
Seems great...i updated the pub here...grab it if you can David and tell me what im doing wrong or is BAD method in the pub..i cant fault the moment (fingers crossed)
The PUB .

Re: Active Window

PostPosted: Tue Aug 12, 2014 10:49 am
by dec

schmutly wrote:So.........what i THINK your saying is its not a good idea to have this running ALL the time as the mouse events are being checked ALL the time...CORRECT?

Not exactly. You can monitor the mouse activity like in the "Inactivity" sample, for example. The problems can begin if you try to show user dialogs (message boxes and something like that) or feed visual controls in a hook event. In these cases the best approach is to stop the hook BEFORE show the user dialog and start it again AFTER the dialog is closed. On the other hand, the sample publications add to a ListBox the events fired by the plugin, but, this is not a good idea and probably is not something we want to do in a real publication.

The problem is similar to add water in a "funnel" to fill a bottle: if we add too much water at a time the "funnel" can be "full of water" and therefore the water come out of the "funnel" and also the bottle. Too much events, too much subroutine executions. Then we need to think what we can do and what we can't do in the hook events. Show user dialogs or fill visual controls do not appear good ideas, for example. Take care about the mouse activity, probably log into a file, appear better ideas of things we can do in such hook events.

Re: Active Window

PostPosted: Tue Aug 12, 2014 4:25 pm
by schmutly
......In these cases the best approach is to stop the hook BEFORE show the user dialog and start it again AFTER the dialog is closed.

Hello, this is exactly what i did...i mentioned i did your suggestion twice and it fixed it as well. And if you checked the pub would have seen its all
ok. So thanks..I'll keep that im mind for future. Stopping hook B4 & after dialog works as suggested with zero side affects so far out of lots of testing.

Thanks again for your time. Remember...some of us (i.e:me :lol: ) are not genius like 3xDavid's,Hans,Gaev etc...and sometimes the docs are not clear
enough for us dumbo' you have to be patient with us, and you all do a great job at that :mrgreen:

Re: Active Window

PostPosted: Tue Aug 12, 2014 7:20 pm
by Tony Kroos
maybe it's a good idea to let the user decide which event to handle atm, to prevent loads of multiple events triggering at once. Maybe it will help to avoid most of such errors. Really, I doubt one would need all events at the same time, in the same pub.

Re: Active Window

PostPosted: Tue Aug 12, 2014 7:36 pm
by schmutly
Hello Tony, this is not for anyone...just for me...and i understand what your saying
but I have been testing it for a whole day now running in the tray and so far no problems.
Nothing slows down, no errors SO FAR
I understand what David means.but it gets disabled in the sub-routine and re-enable AFTER
the dialog box opens.(David's suggestion)
Still testing it..seems fine so far and not sure what errors "would" appear using this?
Those errors seem to appear in NB before i compiled and compiled one 'seems' fine all day.
Will test it all day but its only for me.

Re: Active Window

PostPosted: Tue Aug 12, 2014 9:41 pm
by Tony Kroos
but still... as mentioned above, neobook player runs much more slower than plugin does, and it's single-threaded. Obviously, "bottle-neck" errors will still remain, it's by design. Callback subroutine will not always "return" before new event arrives, and u won't know when it happens but it always will.

+1 to an old suggestions for multithreading... I was asked why nb would need multiple threads - that's one of the answers - more flexible and responsive pubs that meet modern requirements of users and dev's.

Re: Active Window

PostPosted: Wed Aug 13, 2014 4:42 am
by dec

I want to investigate about filter some events, however, maybe the "bottle-neck" occur anyway, since this is not something provided by the Windows Hook API: so the filter need to be made by the plugin, that anyway receive all the events from the Windows Hook API. Anyway I want to investigate it and maybe implement some kind of filter from the plugin. Maybe we cannot get to much gain, but less is nothing.

Anyway I think the above recommendations continue valid in any case: do not use the hook events to intereact with the user and user interface, or, if you use it, take care about stop the hook while doing whatever you wanted.

Re: Active Window

PostPosted: Wed Aug 13, 2014 7:12 pm
by schmutly
Hi David,
I think you answered it thoroughly in the BEGINNING when you recommend
stop the something....start the hook again.THIS WORKS!
The app here.
IF you or someone has time it (it goes to tray.) notepad,word,excel and neobook.
3.Go to each one click LMB in work area just to get focus. dialog (OD) appears..hit ESC.
5.MMB..OD..appears..hit this 3 or 4 times.Quickly if you want.
6.Move onto the next window and do for each.
7.jump back and forth many times.
In MMB,LMB,RMB,LRMLRMLRM ect....madly..lots of times, anywhere..
Nothing bad or weird or errors happen.
You don't have to do this test,of course, but i can't fault it.
However..i added a disable because i DON'T want it running all the time especially
when using Firefox as i use the MMB all the time in disable some tabs..CLOSE the
tabs with this few times...RE-ENABLE 3->7 again.Works fine.

I don't , i'm afraid, understand the bottleneck i am sorry. But answer THIS please.
IS there this "bottleneck" IF.....only IF i did NOT use your stop action....start hook?
In other words would i see problems if i did NOT do your suggestion? my answer is it must be because
there are no problems at all, once i did what you said..none. And in honestly no one unless they're
drunk would click LMB,RMB,MMB madly like i suggest in the test anyway so i don't understand the
"but still.." <-- unless that referred to NOT using your suggestion.

It would be good :
..I want to investigate about filter some events..

but what are the events you are filtering? The LMB and RMB ? I'm only doing something when i hit MMB. And i have NOT
enabled the Keyboard HOOK....only the MOUSE are there NOT only EIGHT events that could happen?
Mouse buttons (up and down)=6 and scroll (U/D)=2.

I dd the above all day and no problems at all....because i DID your suggestion and
STOP...STARTED the hook taking care about what you say.I'm just at a complete loss
that even though i mentioned i USED your advice...and it WORKED that this is still talked
about and it shows my LACK of understanding what your trying to say.
More important is forget my APP for a second...explain, ANYONE, another situation in
the real world where this "plugin" is not a good fit. i ask this because the nature of the
plugin, to MY understanding, is it doesn't matter in what situation you use this plugin
there will BE EVENTS regardless, as its "looking" for events all the time and will run a
sub-routine ONCE that event is fired..and it seems like it is looking for many things
ALL AT THE SAME TIME until...until it "see", for example in my case, the MMB.
Do i have the wrong understanding of this plugin? I certainly don't understand where
the bottleneck comes from IF......IF i do as you say, and stop the HOOK before i do
what i need.
LASTLY....i think its a great plugin... :mrgreen: it's 2 days and for a test i just left
the thing actually enabled and it didn't transport me to Mars or boil the kettle or any
other 'odd' this plugin is great and works well in THIS application
....i AM HAPPY :D

ps: hope the above is not too harsh, its not meant to be in any way..i guess im
like this guy--> :shock: because im waiting for these problems but
on my far..and for last 48hrs its works like any other app..
Have a great day lots of images to edit ..
Thanks David,Tony....cheers

Re: Active Window

PostPosted: Thu Aug 14, 2014 11:09 am
by dec

Unfortunatelly I can't test the application because I do not have Excel nor Word installed. Anyway:

IS there this "bottleneck" IF.....only IF i did NOT use your stop action....start hook?

Yes; when you stop the hook the plugin stop to receive events, and therefore do not execute any NeoBook subroutine. This approach is the recommended way if you want to shown some user dialog. Maybe you no need to stop the hook but anyway you need some "flag" to don't show the user dialog over and over again, which can cause problems. If you use the plugin, for example, to get informed about the user inactivity, you don't need to start/stop the hook everytime. Try the "Inactivity" sample included with the plugin, however, wich use this start/stop approach if I am not wrong.

Re: Active Window

PostPosted: Thu Aug 14, 2014 4:09 pm
by schmutly
OK, thanks David.
Understand and will take heed in future too.
Have a good weekend :)