AlexBelo

Thanks, it works ... now. I did the same thing before but didn't get any results. This is weird ... In general, the home page is a perfect example of very poor usability.

Hi all. Please forgive my ignorance, but I can't figure out how to use the new bug tracker (https://embt.atlassian.net/), for example, get a list of all open bugs. Maybe there is a tutorial somewhere?.. TIA.

Hmm... But how I use such a component for more then 15 years?.. OK, most likely because I always compile monolithic executables. 🙂

But AFAIUI it was not obligatory. Now it's "must" for more-than-Win32 components.

Thank you. Googling "separate packages for runtime and design" returns old but still relevant detailed article: Creating Packages https://delphi.fandom.com/wiki/Creating_Packages

Hi all. I recompile my old 32-bit codebase to use it in Win64 projects. At moment I need to recompile a component with ide designer part (it lives in separate unit). Question: how to configue my package to avoid compilation of this unit?

Hi all. Win64 platform, small console test project. After some days with 11.1.5 I permanenetly get the following message: Debugger fatal error: debug kernel not responding. Cleaning of project, rebooting IDE and Windows do not help. Any advice? --- Upd: it looks like something is wrong in project itself. I can run and debug another test project. Anyway I still need advice what to search/fix in project ...

Thank you for additional information. __fastcall for overlapped virtual destructor of Delphi-based class in CLANG32 compiler https://quality.embarcadero.com/browse/RSP-38783

HI all. RAD 11.1.5 Consider the following code: class dExc : public TObject { public: static int Counter; dExc() { Counter++; printf(" dExc\n"); } /* __fastcall */ ~dExc() { Counter--; printf("~dExc\n"); } }; int dExc::Counter=0; If I compile this in "classic" mode without __fastcall I get: [bcc32 Error] Main.cpp(19): E2113 Virtual function '~dExc::dExc()' conflicts with base class 'TObject' CLANG-32 compiler shows "Success", but program crashes in destructor of ~dExc. Adding __fastcall produces workable exe in both cases. (CLANG-64 version works with and without __fastcall because 64-bit uses its own call convention AFAIK) Is this a bug in CLANG-32 compiler?

Sources are very old and not mine. All compiles fine in 2007 (last ansi version) but now I'm preparing a codebase for unicode and 64 bits. Thanks all for help. BTW I see nothing too strange in code: function SetItemCell operates with pointers on different types (some structures and strings as special case). Nothing nonlegitimate or obscure.

Is this correct New(v); v^:=value; Dispose(v);

Umm... procedure TStringAlignGrid.SetHintCell(ACol,ARow: longint; const Value: string); var v: PString; begin // v:=NewStr(Value); // <--- new AnsiString instance on heap v:=New(Value); [DCC Error] E2008 Incompatible types

Hi all. I'm c-builder programmer and I need some Delphi help. In old pas file which I'm trying to compile I see (simplified): function SetItemCell(ACol,ARow: longint; List:TList; value: Pointer): pointer; var t: pointer; sublist:TList; begin t:=NIL; ... t:=sublist.items[ARow]; sublist.Items[ARow]:=value; ... SetItemCell:=t; // give back the pointer to the previously stored element to let the caller dispose it end; OK, this code puts new pointer into list and returns old contents. Now usage with pointer to string: procedure TStringAlignGrid.SetHintCell(ACol,ARow: longint; const Value: string); var v: PString; begin v:=NewStr(Value); // <--- new AnsiString instance on heap v:=SetItemCell(ACol,ARow, FHintCell, v); if v<>NIL then DisposeStr(v); // <--- delete old string end; No problem in "old Ansi" Delphi versions but now compiler scolds NewStr and DisposeStr as incompatible with Unicode. So a question is: how to create string on heap?

Thank you for tip. According docs it supports all types of applications (including 64 bit BCB). But at moment I have problems: 64 bit app does not start at all, 32 bit app does not show any results ... I'll try asking EL support.

Yes, it was missed libs (*.a). But unfortunately even successfully linked madExcept does not work in my test 64-bit CB exe (nor "mad" exception handling, nor leaks detection) ...