Your Rank: 52
Dimitris wrote: Just before calling the WinHttpReadData everything is OK in my debugging. After that nearly all variables are garbage.
That implies that you are not calling WinHttpReadData() correctly and thus causing memory corruption. What does your code actually look like?
Dimitris wrote: a. I use a pointer from an allocmem of 8K as winhtttp docs suggest here even the needed size of the data as returned by WinHttpQueryDataAvailable is less than 300bytes.
b. The result from WinHttpReadData is true
What does your declaration of WinHttpReadData() actually look like? In particular, is the lpBuffer parameter declared as a Pointer or an untyped 'var'? It makes a big difference in how you pass your allocated buffer to it.
Dimitris wrote: I tried to change the winapi.winhttp and have the declaration from DELPHI 10.1 but even if I change it from notepad and Delphi IDE requests to reload it, the syntax is found incorrect during compile.
You should not make changes to Embarcadero's provided RTL units. You should not have to make such change to get your code working correctly. More likely, your own code is simply using the original declarations the wrong way.
Dimitris wrote: Where is the header file that it is used during compile?
Delphi doesn't use header files, only C++ does.
It has been my experience that trying to post code snippets in this forum is a PITA, no matter whether you use Reply or Quick Reply. It never turns out well. I've given up on it.
Dimitris wrote: I pass a pointer to a cardinal variable and I get unpredictable results
Such as? Can you be more specific?
Dimitris wrote: I noticed now that probably cardinal is not the same thing with longword for the compiler
In 32-bit, it is. However, the API is expecting a pointer to a DWORD, so you really should be using that instead of Cardinal.
The 10.1 declaration is technically wrong. Even when using a 'var' parameter, it should have been typed as a DWORD at least, not left untyped. And was it actually missing the 'stdcall' calling convention, or did you simply omit that?
The 10.2 declaration is more inline with the actual declaration used by the SDK.
The 'lpdwNumberOfBytesAvailable' parameter must be set to nil when WinHTTP is used in asynchronous mode. That is easier to do with a pointer parameter than with a 'var' parameter.
Passing a pointer to a variable is the correct solution in 10.2. What problems exactly are you having when you do it? Please be more specific.
Toby wrote: ...what happens to the object if I reduce the size of the array?
On non-ARC systems (Windows, OSX), the object will be leaked if you don't explicitly Free() it. Consider using a
TObjectList or TObjectList<T> instead of a TArray<T>, let the list free the object for you when it is removed from the list.
On ARC systems (iOS, Android, Linux), the object is reference counted. Its reference count will be incremented when it is added to the array, and will be decremented when the array is shrunk. When the count falls to 0, the object will free itself.
Miguel wrote: For Android the localhost is 0.0.0.0 or 127.0.0.1?
"localhost" is always resolved as "127.0.0.1" (IPv4) or "::1" (IPv6) on all platforms. Even if the OS doesn't enforce that, Indy does, inside of the TIdStack.ResolveHost() method, which TIdTCPClient.Connect() calls when the TIdTCPClient.Host property is not set to an IP address.
Miguel wrote: My code works for Windows FireMonkey on Delphi Xe8:
Not quite, as you have some logic bugs in your code.
On the server side, the TIdTCPServer.OnExecute event handler is fired in the context of a worker thread, not in the main UI thread. You CANNOT access UI controls from a worker thread without synchronizing with the main UI thread. Even on Windows, this is required, but even more so on mobile platforms.
On the client side, TIdTCPClient.Connect() raise an exception if it cannot connect to the server. You are catching that error, but you are then dismissing it and proceeding to call IOHandler.WriteLn() even if no connection was established.
Try this instead:
procedure TForm1.IdTCPServer1Execute(AContext: TIdContext); var MIRec: string; begin MIRec := AContext.Connection.IOHandler.ReadLn; TThread.Queue(nil, procedure begin Memo1.Lines.Add('recebido = ' + MIRec); end ); end;
procedure TForm1.Button1Click(Sender: TObject); begin IdTCPClient1.Host := 'localhost'; IdTCPClient1.Port := 4040; try IdTCPClient1.Connect; except ShowMessage('Connection Unsuccessful: '); Exit; end; IdTCPClient1.IOHandler.WriteLn(Edit1.Text); end;
Miguel wrote: Why my code wont works on Android?
You tell us. What is the actual problem you are experiencing with it? You did not provide any details at all.
Miguel wrote: for Windows its ok...
No, for the reasons stated above.
According to the last published roadmap, Linux support for C++Builder is scheduled to be released in RAD Studio 10.3 later this year. Now that 10.2.3 has been released, an updated roadmap is expected to be published in the near future.
you can use the Win32 API SetWindowsHookEx() function to install a WH_GETMESSAGE or WH_CALLWNDPROC hook in the target application thread that is running the timer. That will give you access to the WM_TIMER messages, which will tell you the timer IDs. However, you won't have any way to know which timer ID belongs to which TTimer component, unless the target app logs that information, or you debug the target app.
You can use the Win32 API SetWindowsHookEx() function to install a WH_GETMESSAGE or WH_CALLWNDPROC hook in the target application thread, then you will receive a copy of the WM_TIMER messages. But that doesn't really tell you WHICH timer is taking a long time to run. WM_TIMER tells you the timer ID, but you won't know which timer ID goes with which TTimer component.
As stated in Indy's installation instructions, installing a new version of Indy will break Embarcadero's LiveTiles framework. That is the error you are seeing. If you are not using LiveTiles in your projects, I suggest you disable/uninstall the LiveTiles package.
"Quick Reply" just gives you a simple Edit field to type into.
"Reply" gives you a full formatting editor.
And it is back up...
And, here we go again....
About meI am a member of TeamB, a highly visible member of the Embarcadero forums, a primary member of the Internet Direct (Indy) open source project, and a contributing author to the C++Builder Journal.