My environment: Windows7 Pro + RadStudio XE4
I am migrating old bcb6 apps to XE4.
In the File Writing, I have to take care of Encoding. So I decided to use TStreamWriter instead of FileCreate() / FileWriter() methods.
In FileCreate() family, I was writing in bcb6
res = FileWrite(handle, line.c_str(), len);
if (res == 0) {
return false;
}
I am rewriting above in XE4 using TStreamWriter
pwriter->Write(line); // pwriter is TStreamWriter * type
// TODO: how about check success or not?
If my understanding is right, TStreamWriter->Writer() method return void.
So, I cannot check the success of pwriter->Writer() method, right?
An exception is raised if a write fails.
Related
Using Embarcadero C++ Builder 10.3.
I have a DynamicArray<uint8_t> myData object. I want to send/write its raw binary content (bytes) to a server using the TIdTcpClient component. I'm going about it like this:
TIdTcpClient tcpClient1;
// Bla Bla Bla
tcpClient1->IOHandler->Write(rawData);
Where rawData should be of type TIdBytes or TIdStream
So basically, it boils down to the following: How to convert myData object to a rawData type of either TIdBytes or TIdStream?
First off, TIdStream has not been part of Indy in a VERY VERY LONG time, which makes me wonder if you are using a very old version of Indy, not the one that shipped with C++Builder 10.3. Indy has supported the RTL's standard TStream class for a very long time.
That being said...
TIdBytes is an alias for System::DynamicArray<System::Byte>, where System::Byte is an alias for unsigned char, which is the same size and sign-ness as uint8_t (depending on compiler, uint8_t might even just be an alias for unsigned char).
So, the simplest solution, without having to make a separate copy of your data, is to simply type-cast it, eg:
tcpClient1->IOHandler->Write(reinterpret_cast<TIdBytes&>(myData));
This is technically undefined behavior, since DynamicArray<uint8_t> and DynamicArray<Byte> are unrelated types (unless uint8_t and Byte are both aliases for unsigned char), but it will work in your case since it is the same underlying code behind both arrays, and uint8_t and Byte have the same underlying memory layout.
Alternatively, the next simplest solution, without copying data or invoking undefined behavior, is to use Indy's TIdReadOnlyMemoryBufferStream class in IdGlobal.hpp, eg:
TIdReadOnlyMemoryBufferStream *ms = new TIdReadOnlyMemoryBufferStream(&myData[0], myData.Length);
try {
tcpClient1->IOHandler->Write(ms);
}
__finally {
delete ms;
}
Or:
{
auto ms = std::make_unique<TIdReadOnlyMemoryBufferStream>(&myData[0], myData.Length);
tcpClient1->IOHandler->Write(ms.get());
}
Otherwise, the final solution is to just copy the data into a TIdBytes, eg:
{
TIdBytes bytes;
bytes.Length = myData.Length;
memcpy(&bytes[0], &myData[0], myData.Length);
or:
std::copy(myData.begin(), myData.end(), bytes.begin());
tcpClient1->IOHandler->Write(bytes);
}
I am using the code below in C++Builder XE4 VCL 32bit. I am using the Indy components, version 10.6.0.497.
I have been using IdHTTP->Get() with HTTP addresses that have now changed to HTTPS. I believe I need to create a TIdSSLIOHandlerSocketOpenSSL component and add it to TIdHTTP as its IOHandler.
When I try to do this, the code below gives the error:
E2451 Undefined symbol 'TIdSSLIOHandlerSocketOpenSSL'
The error is on the code, std::auto_ptr<TIdSSLIOHandlerSocketOpenSSL>.
I am not sure why TIdSSLIOHandlerSocketOpenSSL is undefined, because I have Indy installed and can use TIdSSLIOHandlerSocketOpenSSL as a traditional component from the component palette.
Can anyone show me how I can set this code up to use HTTPS addresses?
std::auto_ptr<TIdSSLIOHandlerSocketOpenSSL> Local_IOHandler( new TIdSSLIOHandlerSocketOpenSSL( NULL ) );
//error: E2451 Undefined symbol 'TIdSSLIOHandlerSocketOpenSSL'
//error: E2299 Cannot generate template specialization from 'std::auto_ptr<_Ty>'
std::auto_ptr<TIdHTTP> Local_IdHTTP( new TIdHTTP( NULL ) );
Local_IdHTTP->Name="MyLocalHTTP";
Local_IdHTTP->HandleRedirects=true;
Local_IdHTTP->IOHandler=Local_IOHandler;
TStringStream *jsonToSend = new TStringStream;
UnicodeString GetURL = "https://chartapi.finance.yahoo.com/instrument/1.0/CLZ17.NYM/chartdata;type=quote;range=1d/csv/";
jsonToSend->Clear();
try
{
Local_IdHTTP->Get(GetURL, jsonToSend);
}
catch (const Exception &E)
{
ShowMessage( E.Message );
//error: IOHandler value is not valid
}
When I try to do this the code below gives the error E2451 Undefined symbol 'TIdSSLIOHandlerSocketOpenSSL'
Add #include <IdSSLOpenSSL.hpp> to your code.
I am not sure why 'TIdSSLIOHandlerSocketOpenSSL' is Undefined because I have Indy installed and can use 'TIdSSLIOHandlerSocketOpenSSL' as a traditional component from the compoenent pallet?
Dropping a component onto your Form at design-time auto-generates any necessary #include statements for you. TIdSSLIOHandlerSocketOpenSSL is no different.
That being said, once you get that fixed, you cannot assign a std::auto_ptr itself to the IOHandler. You need to use its get() method to get the object pointer:
Local_IdHTTP->IOHandler = Local_IOHandler.get();
And you should consider using std::auto_ptr for your TStringStream as well:
std::auto_ptr<TStringStream> json( new TStringStream );
Local_IdHTTP->Get(GetURL, json.get());
// use json as needed...
Though in this situation, I would suggest using the overloaded version of TIdHTTP::Get() that returns a String instead, there is no benefit to using a TStringStream:
String json = Local_IdHTTP->Get(GetURL);
// use json as needed...
My Environment:
OS - Windows7 Pro(32bit)
IDE - RadStudio XE2 Update4
I am wondering about Synchronize() function.
The Synchronize() function is used in the thread program. About using the Synchronize() in C+ builder, the example is as follows ( as can be seen in here)
// Important: Methods and properties of objects in VCL can only be
// used in a method called using Synchronize, for example:
//
// Synchronize(&UpdateCaption);
//
// where UpdateCaption could look like:
//
// void __fastcall TMyThreadClass::UpdateCaption()
// {
// Form1->Caption = "Updated in a thread";
// }
What I am confused is that , in some older version of C++ builder (e.g. bcb6),
the Synchronize() was used
// Synchronize(UpdateCaption);
without "&" before the function name;
Also in the delphi code as in here,
there is no "&" before the function name;
// Synchronize(UpdateCaption);
So, which is the correct way to use Synchronize() in C++ builder
// Synchronize(UpdateCaption);
or
// Synchronize(&UpdateCaption);
I tried both in the actual code, but seems identical in the working manner.
Do both UpdateCaption and &UpdateCaption return address of functions?
So, which is the correct way to use Synchronize() in C++ builder
// Synchronize(UpdateCaption);
or
// Synchronize(&UpdateCaption);
They both work, but & is preferred.
Do both UpdateCaption and &UpdateCaption return address of functions?
Yes. If you refer to a function/method without specifying parenthesis for the parameter list, the address of the function/method is assumed. The & just makes it more explicit.
Delphi Xe.
in delphi help: "...Calling this function usually resets the operating system error state..."
How to reset a current error on 0? I.e. that GetLastError=0
Example:
Try
// There is an error
except
showmessage(inttostr(getlasterror)); // Ok, getlasterror<>0
end;
....
// no errors
....
// How to reset a current error on 0?
showmessage(inttostr(getlasterror)); // Again will be <> 0
You should only be calling GetLastError when there has actually been an error. Some Windows API functions will reset the error to 0 on success, some won't. Either way, you should only interrogate the error state when you need to know the most recent error.
Note that there is a SetLastError method as well, but that doesn't help you; if you set the last error to 0, then of course GetLastError will return 0.
It's actually a Win32 call (not Delphi per se).
You can clear it with "SetLastError ()".
Here's the MSDN documentation:
http://msdn.microsoft.com/en-us/library/ms679360%28v=vs.85%29.aspx
This is an example of low quality documentation. GetLastError WinAPI function will retain its return value until next call of SetLastError so repeatedly invoking will have no effect.
SetLastError(42);
for I := 1 to 100 do
Assert(GetLastError() = 42); // all of those assertions evaluates to True
Also, in Delphi documentation GetLastError has been misplaced into exception handling routines; this is wrong too, these error handling mechanisms are unrelated to each other.
On that silly "usually" word in the reference: It happens because function used to output GetLastError return value invokes SetLastError. Eg:
SetLastError(42);
OutputDebugString(PChar(Format('GetLastError() = %d', [GetLastError()]))); // 42
OutputDebugString(PChar(Format('GetLastError() = %d', [GetLastError()]))); // 0! (ERROR_SUCCESS set by the previous OutputDebugString call)
I've got some code that worked fine under Delphi 2007 but breaks under D2010. It involves passing in a string, converting it to a PWideChar (specifically, a WideString pointer, not a UnicodeString pointer), doing some processing, and then calling SysFreeString on it. It works fine until a blank string is passed in, then SysFreeString breaks. It calls a bunch of things that end up raising an Int 3 breakpoint inside NTDLL.DLL. Continuing past this point results in
Project raised exception class
$C0000005 with message 'access
violation at 0x7747206e: read of
address 0x539b8dba'.
Which, if you look closely, is not the standard Access Violation message.
The top of the stack trace when it hits the Int 3 looks like this:
:774e475d ; ntdll.dll
:774afad0 ; ntdll.dll
:774e5de9 ; ntdll.dll
:774a6dff ; ntdll.dll
:76fc1075 ; C:\Windows\system32\ole32.dll
:770e443a ; C:\Windows\system32\oleaut32.dll
:770e3ea3 oleaut32.SysFreeString + 0x4a
Does anyone have any idea what's going on here?
Edit (from the comments):
This isn't a WideString, though. It's
a PWideChar generated by
StringToOleStr, and there are no
double-free errors when a non-blank
string is passed in. Unfortunately, I
can't really post a code sample
because this is a third-party
component that's under copyright. (And
I can't ask them for support because
it's no longer supported. Basically,
the whole thing's one big mess.)
I'm going to try psychic debugging. You've got some kind of heap corruption in your application and SysFreeString is the unfortunate victim (it's hard to tell without OS symbols, you should probably install the MSFT symbol packages for your OS).
Try enabling application verifier (in particular pageheap) for your app and see if it crashes earlier.
It is hard to diagnose without seeing your actual code, however WideString automatically calls SysFreeString() when it goes out of scope. It sounds like your code may be making a second call to SysFreeString() on memory that has already been freed. WideString itself has not changed at all between D2007 and D2010, but other aspects of Delphi's string handling have. Maybe you are not managing the strings correctly. Can you please show your actual code?
A simple test shows that you need to be really careful on what you do in which order.
So: even though you cannot post a small example, can you indicate what you are doing in a bit more detail?
Bad debugging; ignore the things below; see comment.
The SysFreeString() is being called at the end of the the Allocate() call, even though it returns a PWideChar:
program ShowStringToOleStrBehaviourProject;
{$APPTYPE CONSOLE}
uses
SysUtils;
function Allocate(const Value: UnicodeString): PWideChar;
begin
Result := StringToOleStr(Value);
// implicit SysFreeString(WideChars);
end;
procedure Run;
var
WideChars: PWideChar;
begin
WideChars := Allocate('Foo');
Writeln(WideChars);
end;
begin
try
Run();
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.
Note the console still outputs 'Foo' because the memory has not been overwritten yet.
--jeroen
It can be different reasons of such kind of errors:
You try to free with SysFreeString a memory which are allocated not with SysAllocString, but for example with CoTaskMemAlloc.
You have heap correct.
Heap corruptions are difficult to localize. The function HeapSetInformation can be very helpful. For example you can use
HeapSetInformation(NULL,HeapEnableTerminationOnCorruption,NULL,0);
Other good way is usage of HeapValidate function. For example you can define a function which verify all heaps pf the process (code in C, which can be easy rewritten in Delphi):
BOOL MyHeapValidate (void)
{
HANDLE hProcessHeaps[1024];
DWORD i;
DWORD dwNumberOfHeaps;
BOOL bSuccess = FALSE;
dwNumberOfHeaps = GetProcessHeaps (sizeof(hProcessHeaps)/sizeof(hProcessHeaps[0]),
hProcessHeaps);
if (dwNumberOfHeaps > sizeof(hProcessHeaps)/sizeof(hProcessHeaps[0])) {
MessageBox(NULL, TEXT("GetProcessHeaps()"),
TEXT("Error in MyHeapValidate()"), MB_OK);
return FALSE;
}
for (i=0; i<dwNumberOfHeaps; i++) {
bSuccess = HeapValidate (hProcessHeaps[i], 0, NULL);
if (!bSuccess)
return bSuccess;
}
return bSuccess;
}
The usage of this function can be like following:
void BadFunction(BSTR bstr)
{
LPOLESTR psz = OLESTR("Test12");
lstrcpy (bstr, psz);
}
int main()
{
LPOLESTR psz = OLESTR("Test");
BSTR bstr = SysAllocString (psz);
// verify that before call of BadFunction() all process heaps are OK!
if (!MyHeapValidate()) {
_tprintf(TEXT("heap is corrupted after the step 1.\n"));
return 1;
}
BadFunction(bstr);
if (!MyHeapValidate()) {
_tprintf(TEXT("heap is corrupted after the step 1.\n"));
return 1;
}
SysFreeString (bstr);
return 0;
}
With respect of inserting MyHeapValidate() in different suspected places you can very quickly local the place of corruption.
+1 for Larry Osterman's answer.
Some Windows memory functions behave slightly different under debugger: if they detect some kind of misuse - they trigger breakpoint to notify debugger. So, basically, your code is doing something wrong.
You can install hooks on SysAllocString/SysFreeString and redirect them to your memory manager (which should be in full debug mode) to collect more info. Or you can just pass these calls through to original functions, installing only a filter, which watches for memory actions.
And you can install debug symbols to get more info too (I'm not sure if Delphi debugger can use it, but Process Explorer - can. You can connect it to your process and see call stack).