Leaderboard

Regarding a fix, this is only one of a number of problems with scope resolution in the language. Same issue arises when you use units, where more recently imported symbols hide those from units imported earlier. Same for local variables and methods. Same for local variables and global symbols. Anywhere where you refer to a symbol and there are multiple matches then the compiler chooses the most recent. In princple the resolution is simple. Introduce a new compiler warning whenever the compiler uses this most recent principle.

Debugging was never the issue. That was just annoying. Refactoring was never the issue either. That also is annoying but one of many broken aspects of the refactoring. The issue is the silent bugs that arise when you add a field to a type and that one hides local variables. This has been discussed hundreds of times. Try some more websearch. Then, stop using with.

+1000 And then also introduce proper namespacing and ways to alias things (not only non generic types) at the consuming side (for example)

I did a benchmark with aes software ciphering class, and the win64 is near double faster than linux/osx llvm problem appears that llvm optimizations are not used at all

I always used this code, which works fine. The only issue is if the other application is expecting an input (even a keypress to finish) because ReadFile will wait endlessly as far as I recall. It is easy to finetune it though. function GetDosOutput(CommandLine: string; var ReturnString: String; var ReturnCode: Cardinal): Boolean; const LOGON_WITH_PROFILE = $00000001; var SA: TSecurityAttributes; SI: TStartupInfo; PI: TProcessInformation; StdOutPipeRead, StdOutPipeWrite: THandle; WasOK: Boolean; Buffer: array[0..255] of AnsiChar; BytesRead: Cardinal; WorkDir: string; Handle: Boolean; begin Handle := False; ReturnCode := 255; Result := False; ReturnString := ''; SA.nLength := SizeOf(SA); SA.bInheritHandle := True; SA.lpSecurityDescriptor := nil; CreatePipe(StdOutPipeRead, StdOutPipeWrite, @SA, 0); Try With SI Do Begin FillChar(SI, SizeOf(SI), 0); cb := SizeOf(SI); dwFlags := STARTF_USESHOWWINDOW or STARTF_USESTDHANDLES; wShowWindow := SW_HIDE; //wShowWindow := SW_MINIMIZE; hStdInput := GetStdHandle(STD_INPUT_HANDLE); // don't redirect stdin hStdOutput := StdOutPipeWrite; hStdError := StdOutPipeWrite; End; WorkDir := '.'; Handle := CreateProcess(nil, PChar(CommandLine), nil, nil, True, CREATE_NEW_PROCESS_GROUP or CREATE_NEW_CONSOLE, nil, PChar(WorkDir), SI, PI); CloseHandle(StdOutPipeWrite); If Handle Then Try Repeat WasOK := ReadFile(StdOutPipeRead, Buffer, 255, BytesRead, nil); If BytesRead > 0 Then Begin Buffer[BytesRead] := #0; ReturnString := ReturnString + Buffer; End; Until Not WasOK Or (BytesRead = 0); WaitForSingleObject(PI.hProcess, INFINITE); GetExitCodeProcess(PI.hProcess, ReturnCode); While (Length(ReturnString)<>0) And ((ReturnString[Length(ReturnString)]=#10) Or (ReturnString[Length(ReturnString)]=#13)) Do Delete(ReturnString,Length(ReturnString),1); Result := True; Finally CloseHandle(PI.hThread); CloseHandle(PI.hProcess); End; Finally CloseHandle(StdOutPipeRead); End; end;

One compiler to rule them all and in darkness bind them...

Yes, please! proper namespacing like in Remobjects.Elements would be ...........

This difference will no longer exist when Windows also gets this LLVM compiler

Hello, if you have 2 minutes, please fill out my latest survey. Thanx Mavarik

Don't you just declare the property as TStrings? Use its Text property when you want a string representation including line feeds.

Aha, I understand. It would be more flexible if the IDE would stay on the monitor it was last seen on. OK. I have a rather static setup with my two monitors, so I don't have that issue.

Are those settings really not stored when you save the Debug Desktop?

After a lot of research and experiments I believe that MVVM as it works in other languages which makes it desirable to use is not possible in Delphi at this point. (*) The main reasons for this are lack of language support for things that are achievable in a very compact way in other languages and the way the main UI frameworks work in Delphi. Considering the history and existing support for datasets everywhere I think that separation of business logic and UI can be achieved rather by utilizing this to be able to access plain object with their properties over a TDataSet API to make any DB aware control work with them out of the box giving you all the support that has been there since Delphi 1. (*) "WTF is he talking about?!" - just take ReactiveUI as an example - implementing this in Delphi in a nicely usable way is imo almost if not entirely impossible.

If dragging and dropping in the structures pain does not work I would view the form as text Alt+F12 in my keybindings and move the items in the DFM. If you are not familiar with the DFM format please backup the file first.

I disagree but I am not going into yet another discussion about this.