Well. I being trying to do a update for my programs and they dont seem to be connecting to paltalk even with the right api, Like this straigh up code to send message.

Code: Select all

Dim splitterwindowex As Long, atl As Long, atlaxwin As Long
Dim x As Long, richedita As Long
splitterwindowex = FindWindow("splitterwindowex", vbNullString)
splitterwindowex = FindWindowEx(splitterwindowex, 0&, "splitterwindowex", vbNullString)
splitterwindowex = FindWindowEx(splitterwindowex, 0&, "splitterwindowex", vbNullString)
splitterwindowex = FindWindowEx(splitterwindowex, 0&, "splitterwindowex", vbNullString)
atl = FindWindowEx(splitterwindowex, 0&, "atl:00881030", vbNullString)
atlaxwin = FindWindowEx(atl, 0&, "atlaxwin90", vbNullString)
x = FindWindowEx(atlaxwin, 0&, "#32770", vbNullString)
richedita = FindWindowEx(x, 0&, "richedit20a", vbNullString)
richedita = FindWindowEx(x, richedita, "richedit20a", vbNullString)
Call SendMessageSTRING(richedita, WM_SETTEXT, 0&, Text$)
Call SendMessageLong(richedita, WM_KEYDOWN, 13, 0&)

It don't send the messege, wtf is paltalk doing somehting to stop this

There's a debugger ya know, use it.

Man the code don't got bugs I mean I usually update the program like that checking th new api of paltalk then seeing if it works then using the child insertion, but now is not working, I just want to confirm is my code and not paltalk that has stop it

You got the last richedita right?
Maybe they ignored the WM_SETTEXT message so you may need to use EM_ messages instead.

I think you are making it harder than it need be loco.
The only thing that has changed is the name of the splitter window.

Just use your old code for pal 9.8, and simply replace WTL_SplitterWindow with SplitterWindowEx and it works fine.

In your Paltalk Funtext Source example, this is your send code. I just replaced the old splitter window name with the new one. It works fine on 9.9 build 344

Code: Select all

Sub RoomSend(Text As String)
'this code from locohackers Paltalk Funtext project   
    Dim iHnd As Long
    Dim parent, child, alt As Long
    On Error Resume Next
    parent = FindWindow("DlgGroupChat Window Class", Form1.Combo1.Text)
    child = FindWindowEx(parent, 0, "SplitterWindowEx", vbNullString)
    child = FindWindowEx(child, 0, "SplitterWindowEx", vbNullString)
    child = FindWindowEx(child, 0, "SplitterWindowEx", vbNullString)
    child = FindWindowEx(child, 0, "SplitterWindowEx", vbNullString)
    alt = GetWindow(child, GW_Child)
    alt = GetWindow(alt, GW_HWNDNEXT)
    alt = FindWindowEx(alt, 0, "atlaxwin90", vbNullString)
    alt = FindWindowEx(alt, 0, "#32770", vbNullString)
    iHnd = FindWindowEx(alt, 0, "RichEdit20A", vbNullString)
    iHnd = FindWindowEx(alt, iHnd, "RichEdit20A", vbNullString)
    Call SendMessageSTRING(iHnd, WM_SETTEXT, 0&, Text$)
    Call SendMessageLong(iHnd, WM_KEYDOWN, 13, 0&)
 End Sub

The code in your original post above may also work, but its missing the code to get the main windows class name... which it needs before looking for the splitter window.

Lol, OMGGGGG that was the problem String, Thanks a lot man I was bugging out now it works perfect

locohacker wrote:Man the code don't got bugs

I told ya the debugger was made for a reason.
You had the splitterwindowex but also where it needed to be DlgGroupChat Window Class.

chike, but isnt the debugger the thing the tells ya like when something is not declare

No, that's the compiler. Though basic in theory does not have a compiler but interperter instead the new nasic might fall into the debugger just when a spesific line is executed.
The debugger let you set breakpoints and/or execute line by line and examine the variables so you can quickly find where things go wrong.
e.g. in your code you'd see that the first findwindow had return zero.

Ah, Nice the way you can see where the problem is

Developing software without a debugger is like driving with your windshield covered with mud.
Though sometimes "primitive" methos like logging are more apropriate , it is essential for any kind of software development.

FYI,
For those using the GetListviewItem function, which can be found on this site and is used to get the list of names from a room, the index of the listview column that contains the actual name has changed to 0. It was formally 2.

String wrote:FYI,
For those using the GetListviewItem function, which can be found on this site and is used to get the list of names from a room, the index of the listview column that contains the actual name has changed to 0. It was formally 2.

iSubItem you mean? So how the icons are arranged now do you know?
Thanks for the tip, saved me some time (with the debugger)

Chike wrote:iSubItem you mean?

Yes, myItem.iSubItem = 0

Chike wrote:So how the icons are arranged now do you know?

Using the GetUserStat function below, it returns the following..
cam = 1
red dot = 5
holding mic = 10
hand is raised = 20
While testing, I noticed that if there are two icons in use, it returns the combined value of the two icons.
eg: If user has cam on(1) and hand raised(20), it returns 21.
GetUserStat

Code: Select all

Public Function GetUserStat (ByVal lstviewhwnd As Long, ByVal item As Integer) As String
    Dim result              As Long
    Dim myItem              As LV_ITEMA
    Dim pHandle             As Long
    Dim pMyItemMemory       As Long
    Dim ProcessID          As Long
   ' Dim ItemCount, i As Long
    '***********************************************************
    'open a handle to the process and allocate the string buffer
    '***********************************************************
    Call GetWindowThreadProcessId(lstviewhwnd, ProcessID)
    pHandle = OpenProcess(PROCESS_VM_OPERATION Or PROCESS_VM_READ Or PROCESS_VM_WRITE, False, ProcessID)
    '************************************************************************************
    'initialize the local LV_ITEM structure
    'The myItem.iSubItem member is set to the index of the column that is being retrieved
    '************************************************************************************
    myItem.mask = LVIF_IMAGE Or LVIF_STATE
    myItem.iItem = item
    myItem.iSubItem = 0
    myItem.stateMask = &HFFFF
    '**********************************************************
    'write the structure into the remote process's memory space
    '**********************************************************
    pMyItemMemory = VirtualAllocEx(pHandle, 0, Len(myItem), MEM_COMMIT, PAGE_READWRITE)
    'ItemCount = SendMessage(lstviewhwnd, LVM_GETITEMCOUNT, 0&, 0&)
    result = WriteProcessMemory(pHandle, pMyItemMemory, myItem, Len(myItem), 0)
   
   '*************************************************************
   'send the get the item message and write back the memory space
   '*************************************************************
   result = SendMessage(lstviewhwnd, LVM_GETITEM, item, ByVal pMyItemMemory)
   result = ReadProcessMemory(pHandle, pMyItemMemory, myItem, Len(myItem), 0)
   txtResults = myItem.iImage ' image index in of paltalk  status. 1=cam red dot =5 etc..
    '**************************************************
    'deallocate the memory and close the process handle
    '**************************************************
    result = VirtualFreeEx(pHandle, pMyItemMemory, 0, MEM_RELEASE)
    result = CloseHandle(pHandle)
   
End Function


So all are in iSubItem 0 now instead 0 for cam 1 for hand/mic/reddot & 2 for name before?
Guess I'd have to create classes to handle them now.
The values are decimal or hex?
Cam and reddot make 6? Hand over reddot make 25, or 26 if also reddoted?
I did notice the list look a bit different than it was before.
BTW what is LVIF_STATE for? I recall ir is needed in the invite box but why here?