<p>Am 16.05.2017 02:46 schrieb "Nikolay Nikolov" <<a href="mailto:nickysn@gmail.com">nickysn@gmail.com</a>>:<br>
>> I also no longer have the 'graphwindow' handle variable so I had to comment out anything that was using it like<br>
>><br>
>> SetWindowTextA(graphicwindow,graphwindowtext);<br>
>> And<br>
>> ShowWindow(graphwindow, SW_SHOW);<br>
>> So I just commented them out for now.    I'm hoping there is a way to get around the graphwindow variable because I was using the above 2 functions and I don't know how else to determine the graphic window handle... but the performance gain and ease of implementation will make working out any other issues worth the effort.  Any advice on how I can capture the graph window handle would be appreciated<br>
><br>
> Unfortunately, you can't do that and it's actually the main reason why ptcgraph is fast. Even if you modify the ptcgraph source, so that you get the window handle, it would do you no good, because the window is created in a different thread and this means that you cannot draw to the window from your program's thread. In fact, all the ptcgraph drawing routines actually render to an internal software buffer and issue no winapi drawing calls at all. That's the reason ptcgraph is fast and the regular graph unit is slow - the winapi drawing routines are really the bottleneck in this case and not the speed of the code, generated by FPC.</p>
<p>Hmm? But he only wants to change the tttle of the window. Even on Windows that should work from a different thread. However a platform independent SetWindowTitle() for ptcgraph would be rather useful I guess.</p>
<p>Though I'd like to know why he needs ShowWindow()...</p>
<p>Regards,<br>
Sven</p>