mouse_event vs real mouse event ( gameing bot ) - mouseevent

background :
I wrote a bot to play poker in pokerstars.com. Since 2022 09 14 , the simulation for mouse-move and mouse-click is not working any more.
code:
I used below c# statement to make a click.
enum MouseEventFlag : uint
{
Move = 0x0001,
LeftDown = 0x0002,
LeftUp = 0x0004
}
declaration
[DllImport("user32.dll", EntryPoint = "mouse_event")]
static extern void mouse_event(MouseEventFlag dwFlags, int dx, int dy, int cButtons, int dwExtraInfo);
call
mouse_event(MouseEventFlag.LeftDown | MouseEventFlag.LeftUp, 0, 0, 0, 0);
current situation :
when I need to play a CHECK action, I used to click the CHECK
BUTTON / or it is simulated by my program-bot with mouse_event()
called.
now : the simulation do not work, it looks like ANY PROGRAMMED actions is EATTEN by the pokerstar application. but I can still
click the CHECK BUTTON manually.
I did a search about topics in stackoverflow, experts saying there is NO DIFFERENCE between the manual/simulation click.
any hint to solved this? thanks

Related

STML4 USB virtual com port

I have the nucleo board (nucleo-L4R5ZI) and want to write a code to be able to send data from a uC to a PC via the USB. I followed some tutorials, used STM32CubeMx, other solutions found across the Internet, but anyways I failed. I can open the vcp on the PC side (using Hterm, TeraTerm and Realterm), but cannot get any data.
I use Eclipse and the buildin debugger, which I flashed to JLink.
The main loop:
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_USB_DEVICE_Init();
HAL_Delay(10000);
uint8_t HiMsg[] = "0123456789987654321001234567899876543210\r\n";
while (1)
{
if( CDC_Transmit_FS(HiMsg, 20) == USBD_OK )
{
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_7); // blue LED
}
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_14); // red LED
HAL_Delay(1000);
}
}
After executing this function, the blue LED lights only once and never changes its state (does not blink). It means that the CDC_Transmit_FS(...) returns USBD_OK only once, and next calls give USBD_Busy.
The MX_USB_DEVICE_Init() looks as follow:
void MX_USB_DEVICE_Init(void)
{
USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS);
USBD_RegisterClass(&hUsbDeviceFS, &USBD_CDC);
USBD_CDC_RegisterInterface(&hUsbDeviceFS, &USBD_Interface_fops_FS);
USBD_Start(&hUsbDeviceFS);
USBD_CDC_Init (&hUsbDeviceFS, &USBD_CDC); // I need to init it somewhere so I think here is a good place
}
The CDC_Transmit_FS looks like that:
uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len)
{
uint8_t result = USBD_OK;
/* USER CODE BEGIN 7 */
CDC_Init_FS();
USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDeviceFS.pClassData;
if (hcdc->TxState != 0){
return USBD_BUSY;
}
USBD_CDC_SetTxBuffer(&hUsbDeviceFS, Buf, Len);
result = USBD_CDC_TransmitPacket(&hUsbDeviceFS);
CDC_Init_FS();
/* USER CODE END 7 */
return result;
}
Does anyone know how to make it running? What do I miss?
Best,
This part look suspicious:
result = USBD_CDC_TransmitPacket(&hUsbDeviceFS);
CDC_Init_FS();
The call to CDC_Init_FS() probably kills the packet before it had a chance to be sent to the host.
SO... I found the solution!
I can confirm that the code above works (just remove the CDC_Init_FS)!
Acctully, it was a driver problem. for windows 10 you also need to install it despide what's written in the reference

Why is happened property write error?

c++ : Run time error is happened with error message like this:
RevStrings1->Height of reading included in error: The property is write-protected.
RevStrings1->Height の読み込中のエラー : プロパティは書き込み禁止です.
I'm using c++ builder 3.
This source code can be successfully compiled
setting library, include path and etc.
But run time error is happened.
I guess that this problem is about property read & write.
How can I simplly fix the problem ?
A variable RevStrings1 is created by a class TRevStrings.
//---------------------------------------------------------------------------
#ifndef RevStringsH
#define RevStringsH
//---------------------------------------------------------------------------
#include <SysUtils.hpp>
#include <Controls.hpp>
#include <Classes.hpp>
#include <Forms.hpp>
#include <Grids.hpp>
//---------------------------------------------------------------------------
class PACKAGE TRevStrings : public TStringGrid
{
private:
// void __fastcall SetWidth(int W);
// int __fastcall GetWidth(void);
// int FColCount ;
int FRowCount;
int FFixedCols ;
int FFixedRows ;
int FDefaultColWidth ;
int FDefaultRowHeight ;
int FHeight;
// int FWidth;
int FScrollBars;
int FMaxLength;
bool ColColors[24];
protected:
public:
__fastcall TRevStrings(TComponent* Owner);
void __fastcall DrawCellText(TRect ARect,int ALeft,String S);
virtual void __fastcall DrawCell(int ACol, int ARow,const Windows::TRect &ARect, TGridDrawState AState);
void __fastcall SetColor_Col(int Col,int Row);
void __fastcall SetColorFlag(int Col,bool flag);
bool __fastcall GetColorFlag(int Col);
void __fastcall SetEditText(int ACol, int ARow,const System::AnsiString Value);
void __fastcall Clear(bool ALLorONE,int Position);
void __fastcall DblClick(void);
__published:
// __property int ColCount = {read = FColCount};//FColCount};
__property int RowCount = {read=FRowCount};
__property int FixedCols = {read=FFixedCols};
__property int FixedRows = {read=FFixedRows};
__property int DefaultColWidth = {read=FDefaultColWidth};
__property int DefaultRowHeight = {read=FDefaultRowHeight};
__property int Height = {read=FHeight};
// __property int Width = {read=GetWidth,write=SetWidth};
__property int ScrollBars = {read=FScrollBars};
__property int MaxLength = {read=FMaxLength,write=FMaxLength};
/*
*/
};
//---------------------------------------------------------------------------
#endif
never heard of TRevStrings before
so it is either BCB 3 discontinued stuff (my BDS2006 does not have it at disposal) or you have some 3th party custom package installed but the header file suggest it is based on TStringGrid so if below text does not work for it then you can switch to TStringGrid instead.
in TStringGrid
size properties are accessible normaly:
StringGrid1->Height=256;
StringGrid1->Width=128;
if you want to have size-able col/rows then do not forget to open Options property and set goRowSizing,goColSizing to true and starting sizes are DefaultColWidth,DefaultRowHeight. Here example of usage
// resize the grid
StringGrid1->Height=128;
StringGrid1->Width=256;
// access to Cell AnsiStings
StringGrid1->Cells[0][0]="(0,0)";
StringGrid1->Cells[1][1]="(1,1)";
StringGrid1->Cells[1][2]="(1,2)";
StringGrid1->Cells[2][1]="(2,1)";
// resizing row/col
StringGrid1->RowHeights[0]=15;
StringGrid1->RowHeights[1]=20;
StringGrid1->ColWidths[0]=20;
StringGrid1->ColWidths[1]=15;
As your class is derived from this so this should work also for it if not the there are more possibilities:
you have unrelated bug somewhere
overwriting what you should not damaging the C++ engine your App is running on or have memory leak somewhere or your memory manager is invalidated see
bds 2006 C hidden memory manager conflicts
but that is probably not the case or you are calling VCL/Winapi visual stuff from threads.
To check for all this:
create empty application, add your TRevString and try to set its height on runtime. If no error occurs you have a bug somewhere if error occurs then:
this component is not able to resize on runtime this way
try to use functions like SetSize,SetBounds instead or place the component on some panel align to Client and resize panel
if even this does not help switch to standard TStringGrid
you can also try to cast you RevString to StringGrid first
((TStringGrid*)(RevString1))->Height=25;
Borland compilers sometimes get weird
few times (around 10) over the years I use BCB/BDS the compiler sometimes compile wrongly. The app is running but some code gets distorted or discarted so what helps?
close IDE or even restart Windows
delete all map,obj,tds temp files prior to compiling rebuilding
sometimes is needed that you add empty line of code or swap 2 lines of code
Identifiers/Names collisions
if you name your stuff in similar way to VCL functions then you ask for problems usual error is to name function Draw() ... (use draw() instead and you are fine)
for big projects
if you add your source code as new unit to project instead of just include it (it is present in Object Manager) then in big projects you will got big problems. It looks like units are compiled differently then normal included files in units are expected Formulars and other VCL stuff components so if you got your own non visual classes as units they sometimes stop working as expected creating weird behavior (even your error could be caused by it).
I observe this on BCB5 and BDS2006. In BCB3,BCB4 I did not make big enough projects to spot this and BCB6 is so buggy so its unusable with big projects anyway. By big projects I mean > 1 MB of pure C++ code
The error is self-explanatory - the Height property of the RevStrings1 object is not allowing its value to be assigned. This is evident by looking at the declaration of the Height property in the TRevStrings class:
__property int Height = {read=FHeight};
TRevStrings is going out of its way to make the Height property read-only, overriding the native read-write Height property that is inherited from TControl:
__property int Height = {read=FHeight, write=SetHeight, nodefault};
This is odd for TRevString to do, as it is a visual component that needs to be sizable. Unless it requires a specific height that the user cannot change (in which case declaring the Height property as read-only is not the correct way to handle that - the component should override the virtual SetBounds() method instead and just ignore any new Height value being assigned).
That being said, the reason you see the error at run-time is because the IDE is storing the design-time Height value of the RevStrings1 object in the parent Form's DFM resource at compile-time. That is why you are not finding any RevStrings1->Height in your code - it is coming from the Form Designer instead. The TRevStrings class is not overriding DFM behavior for the Height property, so when the VCL's DFM streaming system parses the Form's DFM resource at run-time, it sees the stored Height value and detects that the object's Height property is actually read-only, and so throws an exception to cancel DFM streaming (and thus the Form's construction).
This is a bug in the TRevStrings implementation. At the very least, if the author had wanted to prevent the Height from being streamed (thus preventing the run-time error), the Height property should have been declared like this instead:
__property Height = {read=FHeight, stored=false};
On a side note, most of the TRevStrings data members (FColCount, FRowCount, FFixedCols, FFixedRows, etc) should never have been declared at all, but instead should have been inherited from the base TStringGrid class.
Whoever wrote this component clearly did not know what they were doing.

How do I draw to the window's title bar in C++.NET?

I'm trying to draw a custom title bar, and I've read that in order to paint outside a window's client area, I need to override WndProc and handle the WM_NCPAINT message. Currently, I'm doing that like this:
//WndProc override
virtual void WndProc(Message% m) override
{
switch(m.Msg)
{
case 0x85: //WM_NCPAINT
case 0x0A: //WM_PAINT
//Call original
System::Windows::Forms::Form::WndProc(m);
//Now we'll do our painting
DrawTitleBar(m.HWnd);
break;
default:
System::Windows::Forms::Form::WndProc(m);
break;
}
}
Which works, because I can put a breakpoint in and it gets hit. If I remove the call to the original, the window's frame isn't drawn. DrawTitleBar looks like this:
void DrawTitleBar(IntPtr hWnd)
{
IntPtr hDC;
Graphics^ g;
//Get the device context (DC)
hDC = GetWindowDC(hWnd);
//Get the graphics
g = Graphics::FromHdc(hDC);
//Draw
g->FillRectangle(Brushes::Blue, 0, 0, 100, 10);
//Cleanup
g->Flush();
ReleaseDC(hWnd, hDC);
}
I first get the DC from the window handle. Then I get the Graphics object by using Graphics::FromHdc. I release the DC with ReleaseDC. Incase there's an issue here, this is how I import the native Win32 functions:
[DllImport("user32.dll")]
extern IntPtr GetWindowDC(IntPtr hWnd);
[DllImport("user32.dll")]
extern int ReleaseDC(IntPtr hWnd, IntPtr hDC);
Also: I've tried a bunch of different methods, all with the same results. I can find a bunch of C# and VB examples on the web, but no C++ examples. I've also read about Windows Vista compatibility being an issue with this sort of thing. Currently, I don't care about that, as I will add it later.
Two simple facts. 1. under DWM GetWindowDC is essentially broken.
2. Two work arounds partially exist A. set compatiblity mode to xp or 98 or 95.
B. program example in msdn social exists. search for
"GetWindowDC broken" then follow a lengthy url to a code
sample [fix the broken url by adding a trailing ) ].
Unhappily, the window shows up with rounded corners on
my box build 9200, win 8.0 , no updates.

Maximizing windows underneath my form

I have a toolbar that is always on the top (topmost = true) but when i maximize other programs the top of their windows is hidden behind it. I want them to maximize BENEATH my toolbar so i can close/minimize them etc... Like an upside down taskbar, literally changing the screen working area...
Is this possible? I have seen it done in "Cairo Shell"
I don't think you achive by use TopMost property of Form. Instead you may need to use SetWindowPos() WIN32 API call
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X, int Y, int cx, int cy, SetWindowPosFlags uFlags);
static readonly IntPtr HWND_TOPMOST = new IntPtr(-1);
If you want to reserve an area on the desktop for your program and make all other programs not use that area when maximized, then you have to register your app to Window's appbar list with the API SHAppBarMessage
I havent found any good code to do this in .Net but if you google it maybe you'll be lucky.
Here are one:
http://www.tek-tips.com/viewthread.cfm?qid=1202570&page=1

How to catch application titlebar change?

We are running on a Windows Client Platform (generally WinXP) in niche industry program that runs in a 640x480 window back to an AS/400 server. To reduce errors I want to watch for when the title bar of the program changes. Then I need to capture the keyboard entries to validate. I'll then make sure each of the entries is valid since the archaic program does no validation. I'll can then do a pop-up then warning the end-user if errors occur and to reduce/eliminate the exception reports.
My question is how can I capture the event of the application title bar change = 'string' that I need? API call? Aiming to do this in VB unless another would be notable cleaner.
WinEvents should work well here. These are lightweight events that get fired when certain UI changes take place - eg names of objects change - which includes Titlebar text changes. One benefit to this type of hook is that you can set it up to deliver the notifications back to your own process, so you don't need to deal with hooking or IPC. (It also works against both 32-bit and 64-bit processes.)
This is easiest to do in plain C/C++; but can be done in .Net (VB, C#) if you add the appropriate [DllImport]'s.
#include <windows.h>
#include <stdio.h>
#define WM_NAMECHANGED WM_APP
HWND g_hwndTarget; // window we're listening to
void CALLBACK WinEventProc(
HWINEVENTHOOK hWinEventHook,
DWORD event,
HWND hwnd,
LONG idObject,
LONG idChild,
DWORD dwEventThread,
DWORD dwmsEventTime
)
{
// Check this is the window we want. Titlebar name changes result in these
// two values (obtained by looking at some titlebar changes with the
// Accessible Event Watcher tool in the Windows SDK)
if(hwnd == g_hwndTarget && idObject == OBJID_WINDOW && idChild == CHILDID_SELF)
{
// Do minimal work here, just hand off event to mainline.
// If you do anything here that has a message loop - eg display a dialog or
// messagebox, you can get reentrancy.
PostThreadMessage(GetCurrentThreadId(), WM_NAMECHANGED, 0, 0);
}
return;
}
void ReportName(HWND hwnd)
{
WCHAR szName[128];
GetWindowText(hwnd, szName, ARRAYSIZE(szName));
wprintf(L"hwnd 0x%08lx has title: %s\n", HandleToLong(hwnd), szName);
}
int main()
{
wprintf(L"Place mouse pointer over window titlebar to report name changes for and hit return...\n");
getchar();
POINT pt;
GetCursorPos(&pt);
g_hwndTarget = WindowFromPoint(pt);
ReportName(g_hwndTarget);
// Note: this doesn't work for console windows, which are managed by CSRSS.EXE. Simplest (though not efficient) workaround for those
// is to use threadId=0 and filter by hwnd in the callback.
DWORD threadId = GetWindowThreadProcessId(g_hwndTarget, NULL);
// This says: call the callback when any UI elements in the specified thread change
// name. _OUTOFCONTEXT means deliver the notifications in this process, don't hook.
HWINEVENTHOOK hook = SetWinEventHook(EVENT_OBJECT_NAMECHANGE, EVENT_OBJECT_NAMECHANGE, NULL, WinEventProc, 0, threadId, WINEVENT_OUTOFCONTEXT);
// TODO: add error checking as appropriate.
wprintf(L"Waiting...\n");
// Thread needs to have a message loop for SetWinEventHook to work for out-of-context messages.
UINT count = 10;
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
if(msg.message == WM_NAMECHANGED)
{
ReportName(g_hwndTarget);
if(--count == 0)
{
break;
}
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
UnhookWinEvent(hook);
return 0;
}
Things to watch for: you might get false-positives; and if the name changes rapidly, by the time you get the first event, the name may be at the second value, so you may appear to see two events for the second value. Neither of these should be an issue if you're just using this as a trigger to check for a specified value, however.
I am assuming that you do not own the code for the target application. In this case, there's no easy "call me back when the title changes" event. You then have 2 options to do what you need, which I will outline below.
Easy but not airtight
Have your application get the main window of the target application (this should be easy enough) and poll its title every 100msec or so. When you detect a change, act accordingly.
Difficult but correct
Hook into the target application using e.g. a global CBT hook. Once your code runs in their process subclass their main window, causing all window messages to go through your code first. When your code sees a WM_SETTEXT message going to the main window, you can actively notify your "other" application on the spot using your choice of IPC. If all you need to do is just shout "hey!" to your other application, do so with an auto-reset event (it will be easiest). Of course all this points heavily to unmanaged code.
If the easy solution is not good enough and the difficult one is too much, you can try using an automation library like White (I 've never used it, so I can't really say more than that).