Paltalk v10.3 build 498

Thanks
Man this ATL: updates are killing the programs ehhehe

@Admin wrote:

Thanks
Man this ATL: updates are killing the programs ehhehe

That is why you need to learn how to enum the windows instead of direct mapping.

When you use Pats (or equivalent) to get the code, it will always be version spacific because you are mpping parent/child windows all the way from top level down to the window you want. If you enum the windows, then often you can go many versions without having to update code.

The ATL changing with every new build is not because the Pal coders are trying to break your integrations, but rather it is because the ATL object is randomly assigned its number during the compile process. This means that it is out of the hands of the developer and handled by the complier application.

Auto you mean like using the Id handles like Chike show in

cause that’s what I’m thinking bout doing right now 🙄

@winter wrote:

@Admin wrote:

Auto you mean like using the Id handles like Chike show in

cause that’s what I’m thinking bout doing right now 🙄

Old: SysListView32
New: SysHeader32

Wrong, SysHeader32 is a child window of bothboth, SysListView and the ATL.

@ChiNa-Man wrote:

Awesome Chike, I was a bit confused over winters reply also, since i can see both!

You can search for the SysHeader32 and take it’s parent, this will work on new and older versions, but why when there is an easier way.

The ID may change, though it hadn’t for a long time.
The function check visability as well as there are duplicates of both the user and room text controlls. It’s weird because it looks like both were duplicated each is visible in one of the groups.

Go with the ID and worry about changes when and if they are made.
You can keep the old code if you wish just add the function and change few calls, depending how clean or messed your code is..