AutoHotkey Community

It is currently May 26th, 2012, 10:23 pm

All times are UTC [ DST ]




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1036 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20 ... 70  Next
Author Message
 Post subject:
PostPosted: October 22nd, 2009, 2:30 pm 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
Lexikos wrote:
Assuming the key isn't defined in a base object, it will merely return an empty string without storing anything. Given that x[y]:="" currently either removes the key (as documented) or does nothing, it wouldn't make sense for x[y] to store a value.
Actually it, removing the key when setting with empty string, is the one currently bothering me in practice.
Quote:
(Well, I think it wouldn't make sense for "get" to store a value regardless...)
Right with AHK as AHK has no concept of undefined, and I realized that creating new key would make meta-functionality useless.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 24th, 2009, 7:35 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
Quote:
Revision 34 - October 24, 2009
  • Changed: Setting a value within an object to an empty string now stores the empty string rather than removing the key-value pair from the object. _Remove can still be used to completely remove key-value pairs.
  • Changed: Command names must be terminated with a space, tab or comma. The following characters no longer bypass this requirement: <>:+-*/!~&|^[]. For instance, syntax errors such as MsgBox< foo and If!foo are now caught at load-time.
  • Fixed: Return now properly handles expressions which result in a variable containing an object. For instance, Return x:=y, Return (x), Return x,... and similar should work now (Return x already worked).
  • Fixed: Multi-parameter get/set did not correctly support meta-functions for multiple objects (such as for x and x[y] in the expression x[y,z]).
  • Fixed: Cascading object-assignments such as the x[y]:=z in r:=x[y]:=z could not yield numbers or objects - broken by L33.
  • Fixed: x._Remove(y) crashed the script or removed the wrong item if x did not contain y.
  • Fixed: x.=y, if x.y=... and similar. May affect other expressions.
  • Fixed: Standalone ternary expressions no longer requires spaces. For instance, x? F(1) : F(2) is now allowed.
  • Debugger: On script exit, disconnect debugger *after* releasing objects to allow debugging of __Delete handlers.


A summary of what I plan to do next (mostly things that have been "discussed" already):
  • Make x.y[z] equivalent to x["y",z]; mostly for objects which rely entirely on meta-functions, such as COMo/COM_L. Where the previous behaviour is required, (x.y)[z] may be used. (Edit: A better way to disambiguate might be: x.y.[z].)
  • Allow dynamically-named method calls (with syntax sugar): obj[name-expression](params) and/or obj.%var%(params).
  • Allow meta-functions to entirely override same-named keys in the base object; i.e. give meta-functions precedence.
  • Replace Object._Insert, _Remove, etc. with ObjInsert, ObjRemove, etc. - these will no longer be pre-defined ._Methods() of all objects.
  • Possibly replace _SetCapacity/_GetCapacity with just ObjSetCapacity, trying to keep it consistent with VarSetCapacity. For instance, ObjSetCapacity(obj) might return the current capacity and ObjSetCapacity(obj,-1) might shrink to fit its current contents.
  • Key/value enumeration functions. For instance:
    Code:
    KeyWasFound := ObjXxxx(obj, key[, value])
    Xxxx may be First, Last, Next or Prev. Basic enumeration code might look like this:
    Code:
    if ObjFirst(obj, k, v)
        Loop {
            ... do stuff with k(ey) and/or v(alue) ...
            if !ObjNext(obj, k, v)
                break
        }
    If something like for k, v in obj is ever implemented, it might rely on these functions by default.
    ObjFirst/Last should provide some way to retrieve the first/last key of a given type, possibly replacing _MinIndex/_MaxIndex. Any suggestions?
I'll start coding these soon (probably in the order listed), so speak now or... think of something less clichéd.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 24th, 2009, 1:10 pm 
Offline

Joined: June 18th, 2008, 8:36 am
Posts: 4923
Location: AHK Forum
That looks very cool, many thanks 8)



Lexikos wrote:
ObjFirst/Last should provide some way to retrieve the first/last key of a given type, possibly replacing _MinIndex/_MaxIndex. Any suggestions?

I would vote to not differentiate between types to keep it simple, it should just enumerate trough all keys I think.
You could always check the type of the key using "If var is type" or "IsObject()" if necessary.
Code:
if ObjFirst(obj, k, v)
    Loop {
        If IsObject(k)
                continue
        If k is not digit
                continue
        ... do stuff with k(ey) and/or v(alue) ...
        if !ObjNext(obj, k, v)
            break
    }

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun :wink:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 24th, 2009, 1:45 pm 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
The code produces a compile error.
Code:
obj.item.add()


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 24th, 2009, 3:51 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
HotKeyIt wrote:
I would vote to not differentiate between types to keep it simple, it should just enumerate trough all keys I think.
That was my intention, which is why I mentioned only First/Last and not Next/Prev. I just think that having both First/Last and MinIndex/MaxIndex seems redundant and could cause confusion. I'll probably add another optional parameter after the value parameter.
Quote:
You could always check the type of the key using "If var is type" or "IsObject()" if necessary.
Yes, but then you would need to enumerate/loop and evaluate keys even though the implementation allows the first or last key of a given type to be retrieved directly, without any searching.

Sean wrote:
The code produces a compile error.
Quote:
Revision 35 - October 25, 2009
  • Fixed: Standalone expressions beginning with two or more "dots", such as x.y.z(). (Broken by L34.) Note that '(' or '[' or ':=' is still required.
    [/list]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 24th, 2009, 7:15 pm 
Offline

Joined: June 18th, 2008, 8:36 am
Posts: 4923
Location: AHK Forum
Lexikos wrote:
HotKeyIt wrote:
You could always check the type of the key using "If var is type" or "IsObject()" if necessary.
Yes, but then you would need to enumerate/loop and evaluate keys even though the implementation allows the first or last key of a given type to be retrieved directly, without any searching.


What types do you think to support?
- integer, string, object ,float, xdigit, alpha, or even more?

Will there still be an option to enumerate trough all keys in one go?

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun :wink:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 25th, 2009, 3:38 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
Quote:
What types do you think to support?
- integer, string, object ,float, xdigit, alpha, or even more?
xdigit and alpha are not types; they are string patterns.
Quote:
Each object contains a list of key-value pairs - each key or value is a string, number or object ...
Integer keys are stored in native 32-bit signed form ...
Floating-point numbers are not supported as keys. Instead they are converted to strings; ...

Source: AutoHotkey_L - Objects

Quote:
Will there still be an option to enumerate trough all keys in one go?
I already said it "was my intention" for those functions to enumerate through all keys, and that I would "probably add another optional parameter" for the type of key. What do you think will happen if that optional parameter is omitted?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 25th, 2009, 12:47 pm 
Offline

Joined: June 18th, 2008, 8:36 am
Posts: 4923
Location: AHK Forum
Okay, I see, that would be great.

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun :wink:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 27th, 2009, 3:07 am 
Offline

Joined: April 22nd, 2009, 6:04 am
Posts: 29
Lexikos,
Thanks for your great Ahk_L version, but It seems like there is limit of a number of 99 gui that can be used in a script.
The first code below doesn't work while the second does.
Are you aware of this limitation :?:
Code:
Gui, 100:+LastFound
GuiHwnd100 := WinExist()
Gui, 100:Add, Button, x17.000000 y26.000000 w184 h54 , Command
Gui, 100:Add, Progress, x18.000000 y101.000000 w185 h28 , 25
Gui, 100:Show, x250 y10 w483 h402, Test
return

100GuiClose:
ExitApp

Code:
Gui, 99:+LastFound
GuiHwnd99 := WinExist()
Gui, 99:Add, Button, x17.000000 y26.000000 w184 h54 , Command
Gui, 99:Add, Progress, x18.000000 y101.000000 w185 h28 , 25
Gui, 99:Show, x250 y10 w483 h402, Test
return

99GuiClose:
ExitApp


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 27th, 2009, 9:36 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
It is a well known and documented limitation of the Gui command in any AutoHotkey version.
Quote:
Each script may have up to 99 GUI windows simultaneously.
Source: GUI: Creating Multiple GUI Windows


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 27th, 2009, 5:43 pm 
Offline

Joined: April 22nd, 2009, 6:04 am
Posts: 29
sorry for my ignorance :oops:
i guest i might have missed that
thanks


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 28th, 2009, 5:03 am 
Offline

Joined: April 22nd, 2009, 6:04 am
Posts: 29
Dear Sir Lexikos,
I would highly appreciate you could implement a loop parsing of an expression to be able to do something like
Code:
Obj := Object()
Obj.color := "Red|Yellow|Green"
Loop, Parse, % Obj.color, |
   Msgbox % A_LoopField
Instead 0f
Code:
color := "Red|Yellow|Green"
Loop, Parse, color, |
   Msgbox % A_LoopField
And if not possible, is there another alternative to this?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 28th, 2009, 7:32 am 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
Lexikos wrote:
  • Make x.y[z] equivalent to x["y",z];
Are you gonna also allow this?
Code:
x.y(z) := "val" ; ObjSet(x,"y",z,"val")


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 28th, 2009, 2:11 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
Sean,
I guess you meant to write [z] rather than (z). I meant x.y[z] in both contexts: v := x.y[z] and x.y[z] := v. (So yes, the latter will be equivalent to x["y",z] := v.) Edit: That said, my earlier statement was a little inaccurate/ambiguous - w.x.y[z] will be equivalent to (w.x)["y",z] and not w["x","y",z]. (If there is no use of __Get, they'll all behave the same anyway.)

wiseley,
I'll consider it, but it probably won't happen any time soon if at all. I'm not sure why you would want "another alternative", and I don't think there is one; assigning the input to a variable is necessary.

FYI, I think that the "% " shouldn't be necessary since there is no ambiguity.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: October 28th, 2009, 3:21 pm 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
Lexikos wrote:
I guess you meant to write [z] rather than (z).
No, I meant (z). Currently x.y(z) := v is a meaningless/incorrect expression, so, how about giving it a meaning?

Restricting the discussion to COM_L, I suppose a lot of users, especially from VBScripts, will attempt the syntax (z) than [z], and the above is the only one not working in COM_L (Get can be replaced with Call as COM_L doesn't differentiate the two). So, if all are implemented, the following two will do the identical jobs with current COM_L, so, an user can choose either () or [].
Code:
v := x.y[z]
x.y[z] := v

Code:
v := x.y(z)
x.y(z) := v


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1036 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20 ... 70  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group