AutoHotkey Homepage AutoHotkey Community
Let's help each other out
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

ISense 1.5.4
Goto page Previous  1, 2, 3, 4, 5, 6 ... 17, 18, 19  Next
 
Post new topic   Reply to topic    AutoHotkey Community Forum Index -> Scripts & Functions
View previous topic :: View next topic  
Author Message
majkinetor



Joined: 24 May 2006
Posts: 3644
Location: Belgrade

PostPosted: Wed May 09, 2007 12:30 pm    Post subject: Reply with quote

Quote:
Alas, however, I tried to avoid any dependency on DOM so far.

Why ?

Quote:
After that, I further replaced the WindowName from CLSID_WebBrowser to the ProgID "Shell.Explorer", so that the scrollbar was auto-generated even without the flag.

It doesn't seem like a good idea for me. You may wont to use IE control for ritch text display with constant page width and height so scroll bars will just spoil the view, and scrollbars will be disabled anyway.
_________________
Back to top
View user's profile Send private message MSN Messenger
Sean



Joined: 12 Feb 2007
Posts: 1388

PostPosted: Wed May 09, 2007 12:54 pm    Post subject: Reply with quote

majkinetor wrote:
Quote:
Alas, however, I tried to avoid any dependency on DOM so far.

Why ?

I liked to keep the job as simple as possible, and I didn't want to step into DOM (I already explained the reason in the IEControl thread). There have been no necessity of it anyway.

Quote:
It doesn't seem like a good idea for me. You may wont to use IE control for ritch text display with constant page width and height so scroll bars will just spoil the view, and scrollbars will be desabled anyway.

As a matter of fact, this was the documented way. Scroll bar was just a side effect.
According to the documentation, we can specify the string representation of CLSID or ProgID as the WindowName. However, there is no mention that we can use the (encoded) GUID.
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 3644
Location: Belgrade

PostPosted: Wed May 09, 2007 1:07 pm    Post subject: Reply with quote

Quote:
There have been no necessity of it anyway.

Well, it would provide extremely interesting features.

Quote:
As a matter of fact, this was the documented way. Scroll bar was just a side effect.

How come that both dll's I have used from different developers didn't have those problems. You could safely disable scrollbars but still scroll using arrows...
_________________
Back to top
View user's profile Send private message MSN Messenger
TheIrishThug



Joined: 19 Mar 2006
Posts: 380

PostPosted: Wed May 09, 2007 1:14 pm    Post subject: Reply with quote

Any chance that you can make it so that the script follows the options of commands that have sub-commands?

Example:
When you first type Gui you get
Quote:
Gui, sub-command [, Param2, Param3, Param4]

Then you if you enter the sub-command of Add, it switches to
Quote:
Gui, Add, ControlType [, Options, Text]

but if you typed Show, it would switch to
Quote:
Gui, Show [, Options, Title]
Back to top
View user's profile Send private message Visit poster's website AIM Address
Sean



Joined: 12 Feb 2007
Posts: 1388

PostPosted: Wed May 09, 2007 1:21 pm    Post subject: Reply with quote

majkinetor wrote:
How come that both dll's I have used from different developers didn't have those problems. You could safely disable scrollbars but still scroll using arrows...

It just hit me. It may be a matter of subclassing implementation.


Last edited by Sean on Wed May 09, 2007 2:09 pm; edited 1 time in total
Back to top
View user's profile Send private message
Lexikos



Joined: 17 Oct 2006
Posts: 2699
Location: Australia, Qld

PostPosted: Wed May 09, 2007 1:54 pm    Post subject: Reply with quote

majkinetor wrote:
Tell me lexikos, did you experience previous bugs ?
Mostly no. The error dialog and invisible-windows-on-reload bug are gone. Smile

The only other "bug" I can think of atm is that command info doesn't work on one-line hotkeys (like +#L::Shutdown, 0.) Nothing major...
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 3644
Location: Belgrade

PostPosted: Wed May 09, 2007 2:19 pm    Post subject: Reply with quote

2 Lexicos
ISense is currently designed to work with commands. Hotkeys are not commands.

Its good to know bugs are definitely gone.


IrishThug wrote:
Any chance that you can make it so that the script follows the options of commands that have sub-commands?

I don't think so. Not because it is impossible, but because such feature would connect ISense to Autohotkey and I don't want that. My idea is to create lang independent Isense. AHK was choosen as initial language for obvious reasons. AHK however have very bad grammar so making AHK isense work in all cases will add lot of special code lines just for AHK language. I also dobut it is possible that general version of ISense works superb with AHK without additional changes (i.e code branch just for this language). This is because AHK can use comma as a parameter delimiter, as expression delimeter and as command delimiter (and all of these are imoprtant for ISense). In other languages there are separate symbols for all those syntax elements.

Although it is trivial to fix, you will probably have to wait until lang-independent ISense is released, from which point it makes sense to make code-branch for AHK.

There is also problem with Loop which has several cases...


Another, much better solution is to use something I noted about Loop. Although are 4 looops are listed, only first one will be displayed no matter if you select others. This is because ISense look for first occurance of the word. Now, I beleive that commands.txt file can be changed to add things like

Gui, Show
Gui, Add,
Gui, Margin
...


as separate commands so when you type Gui, you could be able to see all those chocices. This is simpler and will not create dependecy to AHK language, so maybe I'll do this sooner, especialy as OO languages have overloading that is something similar to multiple gui commands AHK has.
_________________
Back to top
View user's profile Send private message MSN Messenger
TheIrishThug



Joined: 19 Mar 2006
Posts: 380

PostPosted: Wed May 09, 2007 3:40 pm    Post subject: Reply with quote

Ok, I can accept that. But hurry up and get ISense perfect and language independent, so you can put in the AHK branch. Very Happy
Back to top
View user's profile Send private message Visit poster's website AIM Address
Lexikos



Joined: 17 Oct 2006
Posts: 2699
Location: Australia, Qld

PostPosted: Wed May 09, 2007 9:29 pm    Post subject: Reply with quote

majkinetor wrote:
ISense is currently designed to work with commands. Hotkeys are not commands.

Shutdown IS a command.
Lexikos wrote:
+#L::Shutdown, 0

A better example would probably be:
Code:
^f::SendMessage, 0x111, 67, 0, Internet Explorer_Server1, A

I only need to send a single messsage, and I already know what type of window "A" refers to (through #IfWinActive), so there's no need for any more than one line. This IS a command call, but ISense won't show the parameter list for SendMessage because the line starts with ^f::.
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 3644
Location: Belgrade

PostPosted: Wed May 09, 2007 10:07 pm    Post subject: Reply with quote

Quote:
Shutdown IS a command.

Yeah, it is
But Isense scans the line and expects the command to be first thing after whitespace. Well.. you are right, I didn't think about this at all.

I beleive this will be fixed soon. THis only influences post evaluation. While you type, it will still show infowindow.
_________________
Back to top
View user's profile Send private message MSN Messenger
debikkel



Joined: 08 May 2007
Posts: 1

PostPosted: Fri May 11, 2007 6:32 am    Post subject: other languages Reply with quote

Hi

Nice to hear you think about supporting other languages as well. I think you'd want to abstract the language's objects, operators, statements, reserved words and separator chatacters etc. Once that separation is done, all a user needs to do is load up (or write up) their own .txt files.

I am not familiar with the ahk language but it seems all is done in global scope and not in objects (forgive me if I am wrong, this is a quick assumption). If your script would understand objects and a simple list of their props and methods, that would be sufficient for convenient code completion already.

On a sidenote, do understand that you are holding something very powerful here. Generic code completion for potentially any language in potentially any environment is remarkably valuable. IntelliSense from Microsoft is one of the most valuable assets to their Visual Studio ide's, so if you take the right approach here you have a better alternative. Really, do not underestimate what you have here. It takes some more work, but my company for instance will pay if needed once proper javascript/c# code completion would be available in any editor (like our beloved textpad).
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 3644
Location: Belgrade

PostPosted: Fri May 11, 2007 7:29 am    Post subject: Reply with quote

2debikkel

Hi debikkel. First of all, thx for nice words and for seeing the potential and difference in ISense. Many ppl asked me so far why do i reinvent the weel, but ISense is not like other tools of this kind.

Quote:
I think you'd want to abstract the language's objects, operators, statements, reserved words and separator chatacters etc. Once that separation is done, all a user needs to do is load up (or write up) their own .txt files.

There is already separation. AHK commands are in text file (in res folder). You can generaly add missing commands if any. Language independent version would have file like this per language, together with header describing some syntax elements important for this.

Quote:
I am not familiar with the ahk language but it seems all is done in global scope and not in objects (forgive me if I am wrong, this is a quick assumption). If your script would understand objects and a simple list of their props and methods, that would be sufficient for convenient code completion already.

AHK is simple language comapring to mainstreem languages. It is not OO, it doesn't have other scopes then function scope and global scope. So it is very hard to do complete applications in it. Also, AHK hasn't debuger, and other advanced stuff. It is made to do quick lil' scripts in it, between 10-100 lines. The fact that I use it for more serious things is topic for itself. In short, every AHK application can be easily reprogrammed/fixed/changed by anybody knowing basics of AHK. For instance, you don't like ISense tray icon.. kewl... open the code in notepad (no compiling, no libraries, no dependencies no sht you have to think about) and search for Tray - you will find several selfexplantory AHK commands that you can delete, change or do whatever.

ISense can not be compared to InteliSenses of mainstreem IDE's like Visual Studio. Its because real IS, doesn't just monitor keyboard, but have access to the framework so it can get objects properties and methods. Delphi for instance recompiles code on keypress to implement its IS.

Contrary to that, ISense can not access those information other then user provided files. So it has to do things from different perspective, anylizing input and comparing to previous input states. This can not match power of mainstreem InteliSenses by Borland MS or others.

Anyway, ISense is not made for such usage. Its made to fill holes around. I use EditPlus, but I don't do C# in it. But for AHK, Python, Perl, Lua, JavaScript and similar I use from EditPlus to whatever happens to be there. This is when ISense should come into action. Furthermore, its not easy to catch generic language concepts that influece this tool - overloading, named parameters, syntax suggars, etc...

As I also want it to work with JS code I will see if something can be done with objects. Anyway, I am not sure I can say if/when will that be done.

Quote:
It takes some more work, but my company for instance will pay if needed once proper javascript/c# code completion would be available in any editor (like our beloved textpad).

Its not trivial to monitor all that user can do with the keyboard. ISense works like finite automata. It doesn't have linear state change and state network is more complex with every new version.


Quote:
It takes some more work, but my company for instance will pay if needed once proper javascript/c# code completion would be available in any editor (like our beloved textpad).

I just checked TextPad and it works well with Method2. I added it among confirmed editors.


Thx for your feedback.
_________________
Back to top
View user's profile Send private message MSN Messenger
Rajat



Joined: 28 Mar 2004
Posts: 1718

PostPosted: Fri May 11, 2007 10:27 am    Post subject: Reply with quote

I'd like my all-time running script to run iSense when i open my script editor and close it when i close the editor (like it does for my intellisense). what's the best way to close iSense without being brutal?
i'm not too sure if the way i use with intellisense will go down too well with iSense if it saves some settings on exit.
_________________
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 3644
Location: Belgrade

PostPosted: Fri May 11, 2007 11:30 am    Post subject: Reply with quote

Well, ISense is made mergable, as I described in the article.
So, it can run within PARENT script, which controls it.

This is the initialisation function for mergable script (mandatory):

Code:
ISENSE_Init( lastGUI=0, subMenu="", bStandalone=true )


lastGui is the number you give to Isense from which it starts to create its own windows. Function will return you last number it used so you can continue with other mergable scripts.

subMenu is name of the Tray submenu you want for Isense to show its otherwise tray menu. In merged environment, Parent is responsible for the tray, so ISense will not act on Tray menu but will use submenu name you give to it.

bStandalone is by default true. If you set it to false, ISense will understand it is runned in other envirinment (PARENT).


INTERFACE
ISense_WatchForInput()
Start the ISense main loop. This routine is called automaticaly if ISense is run standalone.

ISense_OnOffKeyHandler:
This is routine to enable/disable ISense. Alternatively, you can set ISense_Off := true


Simple PARENT script:
Code:
   g := 1
    g := Scritp1_Init(g, "Script1", false)
    g := Script2_Init(g, "Script2", false)
    g := ISense_INIT(g, "ISense", false) 
    g := Script4_Init(g, "Script4", false)
return

F5:: ISense_WatchForInput()
F6:: ISense_off := true

#include ISense.ahk


However, it doesn't work like it should in this latest version. First of all, you must say true, instead false in INIT or Info window will be empty. Next, there is currently no way to exit the WatchForInput function. Afteer Isense_off := true it will still enter the function, just to see its off and to return. I didn't update this part of the script as I realised it is the best for ISense to be standalone as of constant looping while monitoring (thus preventing other scripts in merged environment to work correctly). If you want I will provide you ways to exit this function. Also, ISense dynamicaly does off/on depending on what you do

Besides all that, ISense is designed from the start to be mergable, so except threading problems you may have nothing else in outer world will be compromised.

If you are interested in details about this technology I can point you to my article about script merging with some easier examples to follow.

BTW, no settings are saved on exit.
_________________
Back to top
View user's profile Send private message MSN Messenger
Lexikos



Joined: 17 Oct 2006
Posts: 2699
Location: Australia, Qld

PostPosted: Fri May 11, 2007 11:52 am    Post subject: Reply with quote

Rajat wrote:
what's the best way to close iSense without being brutal?
A quick test shows that using WinClose on a script's main window causes the script to cleanly exit (that is, it runs the OnExit sub-routine.) This would most likely be true for all scripts. (Though it might not actually close the script if OnExit doesn't call "ExitApp".)
majkinetor wrote:
BTW, no settings are saved on exit.
Though there is an "empty" OnExit handler...
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    AutoHotkey Community Forum Index -> Scripts & Functions All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6 ... 17, 18, 19  Next
Page 5 of 19

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum


Powered by phpBB © 2001, 2005 phpBB Group