x64 compatibility

[cristianbuse]

Can you update the API declarations for x64?

[Greedquest]

Bit of a funny one; most of the api declarations are already 64-bit but need the ptrsafe attribute (easy fix). However one 64 bit change is that Scripting.Dictionary can't accept a LongLong key for some reason. So I need to come up with something other than callback function / object pointer to use as the key in the timerInfo dictionary

[cristianbuse]

Yes, it's a bit annoying. One other thing that I don't like about dictionaries is that you cannot have an Empty key. It just simply views it as 0. Because of the 2 issues I've skipped using a dictionary entirely when I revived my old array library. I simply made a GetUniqueTextKey private function to make sure I can generate a unique key per value/dataType in a Collection in a similar way with a dictionary but without the 2 issues. I'm sure you've already thought about using CStr(ObjPtr(obj)) as key and CLngPtr(key) for usage, with some conditional compilation for x64.

I've created a repo with a file that I worked on a while ago. It was a dead end but I learned a few things. I sent you an invite. I think it will be worth the read. Ping me in that repo if you have any questions.

[Greedquest]

Thanks for the link to the file, I'll take a look!

And yeah, I'm just annoyed because the LongPtr actually had some meaning; it is the id param of the TIMERPROC and so is passed to every callback by WinAPI, meaning those callbacks have the data needed to access their own timer instances which is nice. Now I'll have to add some layer of abstraction (just stringifying the key probably) to turn a timerID -> TimerDictKey, which is just another annoying bit of complexity to worry about that doesn't add any value. I suppose your GetUniqueTextKey function generates a key which the caller has to keep a track of if they want to access their stored item later on? Or is it a 1 way hash that means you can have any data type key but internally that is represented as a hash string - so the original key data isn't retrievable but its hash is saved for the lookup?

[cristianbuse]

It's just a one way hash used for filtering and getting unique values. I've exposed a couple of UDFs in that project and for the DM_FILTER UDF it is possible to use "IN" and "NOT IN" operators. The provided list gets "hashed" into a collection using the mentioned function and the collection is later used (e.g. IsValuePassingFilter method) to check if other values are in/not in the collection (where of course the values use the same GetUniqueTextKey function). Not the best approach but gets the job done.