SciTE Jump - Navigate between functions and regions in an AutoIt script

[mLipok]

I notice:

 

OK

Line 143  (File "C:UsersuserAppDataRoamingSciTE JumpBinMonitor.a3x"):

 

Error: Missing right bracket ')' in expression.

 

 

EDIT:
I use last BETA SciTE

Edited October 12, 2013 by mlipok

[Guest]

This update includes a bug fix I came across whilst testing as well as a request by gil900.

I've also included a ZIP file on the download page for those who are a little reluctant to use the Portable installer.

It should be noted that I haven't updated the language strings from the previous version, please check your language of choice and feel free to send an updated version if not done so already. Download is available in the original post.

Language Changes:

Changelog:

 

Thank you.

But the link to the zip file does not work.

You need to fix it ..

But anyway I used the exe file (it can be downloaded)

And I see you've solved the bug.

But you created in addition to more serious bug.

What happened in the previous version is that when clicked in the line field then your tool automatically jumped to the line number in the field. this scenario is good and acceptable because it's a good way to jump again and quickly to the line that i typed before. what is not good in the the previous version is that this tool also automatically jumped when just clicking on the window of the tool.

your bugfix actually totally disabled the automatically jumping case,

What you should do is that the automatically jumping case will occur only when clicking inside the line field with the mouse (if a line number is written inside this field).

This should be the only trigger(click inside the line field) for activate the automatically jumping case.

[guinness]

I notice:

EDIT:

I use last BETA SciTE

Delete Monitor.a3x and try again. Could also tell me which version you're using please as the current stable version doesn't have this issue.

Thank you.

But the link to the zip file does not work.

You need to fix it ..

But anyway I used the exe file (it can be downloaded)

And I see you've solved the bug.

But you created in addition to more serious bug.

The download is correct, but it appears to be an issue with ge.tt's servers.

I haven't introduced as this was a design choice, I didn't think you would see this as an "issue", so I will try another workaround. Please try this version >> SciTE Jump v2.12 and then I will look at publishing if it meets your requirements.

Edited October 13, 2013 by guinness

[mLipok]

Delete Monitor.a3x and try again. Could also tell me which version you're using please as the current stable version doesn't have this issue.

 

After "delete" all works OK

SciTE Jump_v2.11.exe

[guinness]

After "delete" all works OK

 

SciTE Jump_v2.11.exe

Great. I think it's because you had the beta version of Monitor.a3x that was compiled with AutoIt beta v3.3.9.21.

[mLipok]

quite possible

[guinness]

Updated the download of the next version. Now _ArrayUniqueFast() is case-sensitive with the use of converting the string to binary.

[mLipok]

There is still one problem

 

Description of the problem:

I started maximized window SciTE

I press ALT + Q opens SciTEJump and docked to the left side

Now close SciTEJump

 

At this point SciTE should return to their original size.

In this case, the maximized window.

 

The problem is that when you start SciTEJump not remember SciTE window parameters.

[guinness]

 

There is still one problem

 

Description of the problem:

I started maximized window SciTE

I press ALT + Q opens SciTEJump and docked to the left side

Now close SciTEJump

 

At this point SciTE should return to their original size.

In this case, the maximized window.

 

The problem is that when you start SciTEJump not remember SciTE window parameters.

 

OK, I will have a look at fixing in the next release v2.13.

[Guest]

Delete Monitor.a3x and try again. Could also tell me which version you're using please as the current stable version doesn't have this issue.

The download is correct, but it appears to be an issue with ge.tt's servers.

I haven't introduced as this was a design choice, I didn't think you would see this as an "issue", so I will try another workaround. Please try this version >> SciTE Jump v2.12 and then I will look at publishing if it meets your requirements.

I see that in this version when pressing the space button then your tool is jumping again..

it is better than before but it's not what I wanted. i want that when clicking on line field then your tool will jump again.

the the reason why you had a bug is because of the condition that triggers the jump case was not correct.

your condition  was somthing like:

if line filed is active And the window of the tool is active And line <> "" Then  the jump case will happen.

your reson why it lead to bug is that :

after activating the line filed(by clicking inside the filed) then the line field will remain activated even after unactivating the window of the tool.

so what heppen when you activating again the window of the tool then the condition  will trigger again the jump case because the line filed was activated.

the bug will not happen if you will unactivating the line filed manually(by clicking inside other filed )

at this case the condition will not trigger the jump case because  the line filed was nat activated.

Possible solutions:

1) the line filed will be automatically unactivated after the main window of the tool was un activated or after the jump case was triggered.

2) add to the condition that triggers the jump case the following "and":

... and MouseGetPos() = <Region above the line filed>

I hope that now you understand..

Thank you for trying to solve the problem!

Edited October 13, 2013 by Guest

[guinness]

So you basically want me to deactivate the line input field when SciTE Jump doesn't have focus? This isn't a bug, just a design requirement you're expressing. Also this has always been like this.

I will have to think about adding a setting because in windows the caret will remain in the last input field selected whether the GUI has focus or not, so this is what users expect and thus overriding it will cause complaints.

Edited October 13, 2013 by guinness

[guinness]

Though by all means edit the code and send to me and I can then work out whether or not to add to the next release.

Edited October 13, 2013 by guinness

[Guest]

So you basically want me to deactivate the line input field when SciTE Jump doesn't have focus? This isn't a bug, just a design requirement you're expressing. Also this has always been like this.

I will have to think about adding a setting because in windows the caret will remain in the last input field selected whether the GUI has focus or not, so this is what users expect and thus overriding it will cause complaints.

i hope that you understand what I mean when I said "deactivate the line input" ..

I write with google translate and i don't know how to call this.

"deactivate the line input" is that the caret will not remain in the line input.

you can do the solution 2 that i suggested you:

2) add to the condition that triggers the jump case the following "and":

... and MouseGetPos() = <Region above the line filed>

with this solution you don't change any requirement for fixing the bug..

but you will have to write code that will return the <Region above the line filed> .

[guinness]

I don't think you understood my point when I said deactivating will cause complaints. This is a standard feature of Windows that when you go back to a window the caret is in the same input as before. Deactivating will cause users to wonder what is going on as I will be overriding the default.

Another point is using MouseGetPos() is quite a clumsy workaround and doesn't really resolve the issue (unless you've tested it?!) as Windows doesn't register a message when the caret is already present in the input, therefore adding your solution wouldn't work as that's where the line input jump is triggered in WM_COMMAND.

[guinness]

 

There is still one problem

 

Description of the problem:

I started maximized window SciTE

I press ALT + Q opens SciTEJump and docked to the left side

Now close SciTEJump

 

At this point SciTE should return to their original size.

In this case, the maximized window.

 

The problem is that when you start SciTEJump not remember SciTE window parameters.

 

Fixed in v2.12, see download above.

[mLipok]

Fixed in v2.12, see download above.

 

Confirm as Fixed

Thanks

Best regards

mlipok

[Guest]

I don't think you understood my point when I said deactivating will cause complaints. This is a standard feature of Windows that when you go back to a window the caret is in the same input as before. Deactivating will cause users to wonder what is going on as I will be overriding the default.

Another point is using MouseGetPos() is quite a clumsy workaround and doesn't really resolve the issue (unless you've tested it?!) as Windows doesn't register a message when the caret is already present in the input, therefore adding your solution wouldn't work as that's where the line input jump is triggered in WM_COMMAND.

 

standard feature of Windows that when you go back to a window the caret is in the same input as before. Deactivating will cause users to wonder what is going on as I will be overriding the default.

yes, i understand your point. and am not saying that this is the bug...

 

Another point is using MouseGetPos() is quite a clumsy workaround and doesn't really resolve the issue (unless you've tested it?!) as Windows doesn't register a message when the caret is already present in the input, therefore adding your solution wouldn't work as that's where the line input jump is triggered in WM_COMMAND.

Can you tell me what area in the source code is the jump to line event?

i will try to do a bugfix and i I'll write the here my patch code

Edited October 13, 2013 by Guest

[guinness]

Look at WM_COMMAND, but it's not the issue of implementing, just interested how you came to the idea MouseGetPos should be used.

[guinness]

gil900,

Try the version here >> 

[Guest]

gil900,

Try the version here >> 

Now I tried this version and I also tried this version before you sent this message.

And what I realized is that it is not the same exe file. Have you changed the download link?

The version number is the same but the exe is not.

Today I was busy in my project so I could not try to fix this bug.