Hi,

i saw that the new FTP client is based on the graphic lib QT so that AHK cannot handle it.

With the help of the AHK build in funktions like getWindowId you get the HWND of the window.
Now you could load the QT DLL and resove the HWND to and QT class and handle it with the QT lib and make clicks and other things with the help of AHK.

I don't really know if this would work so i want to know if somebody knows if this should work.
If somebody knows it works i will give it a try and build/fix some of the tools worked in former times before the update.

If you are going to go to all that trouble, people might as well write c++ programs to interact with QT (as that is what QT is written in).

IF you have any links/resources I could read on how I could use QT.DLL (or whatever) to interact with the controls in a FTP table I'm all ears... currently wondering wtf, don't know how on earth I'm gonna get some of my scripts working again

I doubt there will be much you can do if the QT widgets aren't built on top of GDI windows, etc. Pixel-search and post-message will prolly be the only option

Juk

I dont think its possible to interact directly with the qt controls like you could with the windows controls. QT uses the uxtheme.dll directly to emulate the look and feel you have from your windows skin if I remember correctly, they dont use native windows controls in any way. Instead of OCR I dont see any other way .. if someone does, please enlighten me.

Stupid full tilt, they give modders a few months in advance with the beta but they wait with the new UI framework untill its final.

Somebody that can write a very basic version of FT shortcuts in C++ or whatever else works is going to make a lot of money.

So the UI thing was not part of the beta?

No, it was not. Atleast, not with the QT framework. I am (was?) developing a new application that interacted with ftp. I tested it against the running ánd the beta version, both used native windows controls. The beta they deployed did had all the new graphics things but it did not used the qt framework. I think they did that on purpose to block tableratings and other ****.

My researches are at the beginning but i can say one thing:
You don't need to strungle with ORC!

dave: i'm reading the QT docs from qtsoftware.com and some windows API stuff/AHK docs

Maybe I can release the first testscript/programms later today.
I don't know in which language i will write them C++ or AHK.
I choose the easyer one.
For some reason i don't like the thought of learning C++ although i'm using plain C for years now.

I would be verry interested in these samples. Could you tell us where you are exactly lookin in the QT documentation?

Couple things:

QT uses the native OS rendering APIs, at least in recent versions, and assuming you're using one of the Windows-y styles, and assuming you're not running in Classic mode, etc., etc., etc., the drawing is done through UXTHEME.DLL. That does NOT mean that there's an underlying window (HWND) and that does NOT mean there's an underlying widget object you can "get at" in C++. There *might* be, but you can always simply blast pixels to the screen and not have any underlying constructs whatsoever, and that's true of QT and any graphical subsystem for that matter...

Clicking the mouse shouldn't be a problem (you can always tell the machine to arbitrarily click location x,y whether or not there's a window - you don't need to post a message necessarily) but reading text....for reading text you are literally going to have to either a) sift through process internals or b) perform OCR unless you're very lucky and c) that text is still alive in the widget subsystem. I don't think this is very likely to be the case because I agree with one of the earlier posters as to the motivation behind this change.

no of my original ideas workt as they should all ended (how should it end in a other way) in an access violation.

At the moment i try to find out how squish is doing it.
It seams like they inject their own QT lib and make the job through that ... but i think this will cause FTP to instantly ban you from ftp -.-

If you write your own QT you could make it suiteable for the winapi but that would be a big job...

So i rebuild the QT libs to look if this way may would work ....
It compiled fine.... but Fulltilt didn't run with it.
I will review where this issue could be based in.
May its only some incompatible versions of compiler/linker or something easy to fix.

If this isn't this option is failing to .... ok i don't think fulltilt would like it ...

I also was working on a add-in for FTP, now it seems like I've wasted about 20 hours of coding. It's been a while since I've used QT, but my guess is that FTP is no longer using WM_USER messages to pass game information to the window. Most likely they are using a subclassed QEvent or QT slots, I don't really see a way to hook into these without changing the QT dlls since QtWndProc will not receive the QT events or messages.

Anyone interested in exchanging some ideas about how to work around this please send me a private message, I'd like to keep this kind of info off the public forums if possible. It really seems like this move was to lock out 3rd part applications, completely changing the gui subsystem is not a trivial thing.

Thanks.

One of the key advantages of AHK was transparency. If poker utils have to be compiled, there are serious security / trust issues to overcome that will impact their commercial success.

But...see my post above re: compiled apps and transparency.

I think this won't be a problem if you publish the sources of the programm...

.

thus killing the "making lots of money" part

Did you reg as IceM on QTForum? I noticed a "please help" post re: "an application that recently underwent a major update"!

I agree that writing your own QT lib will result in major security issues (and rightfully so). What a mess....I wonder if the lack of warning was a heavy-handed solution to PTR and datamining sites in general, no matter what the effect it would have on scripts (or perhaps scripting is being discouraged too, they just don't want to admit as much)

No, that was me. I could not find any other community forum of QT besides that, so I gave it a shot. I dont have any experiance in QT programming so I took a shot there. The forum seems kind of inactive though, so I dont expect much. I am still waiting on my evaluation copy of Squish to see how they do it.

About your closed/open source thing. There are allot of applications provided as binaries to help people play poker (shortcuts, table scanners, whatnot). Keeping things closed is a non argument for me. I dont think you can compare AHK to any 3rd generation programming language like c++, c# or java (granted, I have no experiance in AHK also, but it seems to be just a simple scripting language).

I still dont understand why they ported this to QT. If they did it to prevent people retreiving information with api calls there would be allot of other, not so drastic solutions (its not that hard to filter and ignore the api messages).

Edit: and about modding the QT lib, i dont think this is the way to go. FTP will probebly ban that as soon as its wide spread, its pretty easy for them to detect and just not startup at all.

Anyone have an idea how rvg72 and mr.snood have fixed HEM and SpadeIt?
They get information out of the client for the tablescanning.

They use OCR, so it is painfully slow.

I have a working test that I made that gets valid QWidget pointers to the controls so I can use the Qt API in my applications to access them. Not sure if anyone is interested in the details though.

No, I understand what you are saying, but I would classify the current group of compiled apps (HEM, PT etc) slightly differently - at some point, to achieve complicated functionality and high performance you just have to trust the developer. But I would not be an early adopter of any compiled application when the security of my PC and poker account was at stake.

There are dozens (actually more like hundreds) of scripts that anyone can develop and publish to the community, and in an open format can be immediately identified as being safe or not, which is almost always more important than being high performance, for poker player's needs. That sector has been wiped out with one stroke.

I thought they just switched to server-side table scanning.