-
Content Count
135 -
Joined
-
Last visited
Posts posted by Steve Maughan
-
-
On 1/28/2024 at 10:36 AM, Lars Fosdal said:Well, my "you" was the general "anyone". And the argument stands: why would anyone chose not to use the massive tooling that already exists for Blazor? Embt would end up in another trying to catch up situation like they did with .net.
Hi Lars,
You may be right but I find parallel with the current situation with Blazor and 1994 with VB 3. When Delphi was launched VB had first-mover advantage in the RAD development market. There were lots of ActiveX components. Then Delphi came along and provided a cleaner way to develop and the executables were lightning fast. Now we have Blazor and all of the .net luggage that needs to be installed. To me Blazor seems cluncky in the same way VB was clunky back in 1994. I see a sizable gap in the market for Blazor challenger. The key components would be a page-builder (like the ones for WordPress), the ability to drop controls on GUI and change properties, and then create events and code in Delphi / Visual Pascal. If the whole app was then compiled to WASM and run on any browser that would be wonderful. But you might be right, it might be too much for Embarcadero to pull off.
Steve
- 1
-
4 hours ago, Lars Fosdal said:Why not stay with C# if you want to do Blazor?
That is where the tooling is, and the language is not that different from Delphi.
Hi Lars — I don’t have specific project need. This post was more of a desire for Embarcadero to move in this direction.
-
Blazor is an interesting technology: web development using C#, compiling to WebAssembly. There’s also App Builder that can do create Blazor GUIs in a RAD style environment.
Does anyone know of any plans to do something similar with Delphi? It seems this would be in the original spirit of Delphi i.e. RAD development compiling to native executable. I know there are things like TMS WebCore, but they compile to JavaScript, whereas WASM would (I assume) be significantly faster.
Thoughts?
— Steve
-
-
@Cristian Peța this version works perfectly. Many thanks — I owe you one!!
@Brian Evans Thanks — that makes sense.
@Attila Kovacs thanks for the input!
— Steve
-
Hi Cristian — many thanks but the file you uploaded is identical to the original. Is there a patched version? I owe you bigtime!
— Steve
-
@Cristian Peța you found it!! When I disable the ASLR in Delphi 11.3 it also runs fine in 64 bit mode. That makes sense. MANY THANKS!
Now the question is, how do I make it work with ASLR enabled.
— Steve
-
21 minutes ago, Attila Kovacs said:"Data" is not initialized in your demo
GetMem(Data, iRecordLen);
and that's it, it ponts to trash
Thanks Attila, but I didn't think "Data" needed to be initialized. The GetMem function is asking the OS to allocate some memory of length "iRecord", and sets "Data" to point to the start of the allocated memory. Is this not correct?
— Steve
-
I recently updated to D11.3 for AlignMix, our mapping solution. We were previously using D11.1. We have old code that reads a DBF file. This is used to read the DBF files associated with ESRI Shapefiles that contain geographic data. The code had worked for eight years without a problem. It still works in 32 bit mode but now doesn't work in 64 bit mode and gives an error. The DBF reading routine contains code that casts blocks of memory as strings etc — this is probably the root of the problem.
If anyone is interested, I've attached a sample project that reads a DBF file using the code.
In the sample project I only get two warnings:
[dcc32 Warning] uDBF.pas(155): W1000 Symbol 'StrPas' is deprecated: 'Moved to the AnsiStrings unit'
[dcc32 Warning] uDBF.pas(216): W1057 Implicit string cast from 'AnsiString' to 'string'
Are these relevant?
Question: what changed between D11.1 and D11.3 that could cause this type of problem? Was there any change involving casting of strings in 64 bit mode?
All help appreciated!
Steve
-
Quote...Chess isn't very computationally heavy....
I can't tell if you're joking or not. There are not many tasks more computationally intensive than chess.
Of course I'll benchmark but just wanted to know if anyone had any broad-brush insights that could save me some time.
Thanks,
Steve
-
I've used Delphi since it was launched in 1995 and never explored the FPC. Now I'm tinkering on developing a chess engine. For this I'd like the EXE to be as fast as possible. I assume Delphi produces faster EXEs than FPC. Is this correct? I Googled around and the only posts were 10+ years old. They implied Delphi was faster — sometimes by quite a bit. Has anything changed?
— Steve
-
@Fr0sT.Brutal This looks ideal. I'll delve in a try to implement this approach
@FPiette thanks also, this looks good too!
— Steve
-
I've added the "flush(Output)" command after the "WriteLn" statements and it seems to be working. Any advice on getting the ensuring the fastest possible communication via StdIn and StdOut would be appreciated!
— Steve
-
5 hours ago, FPiette said:I read in UCI specification: "the engine must always be able to process input from stdin, even while thinking.".
Are you sure it is the case with your engine ?
@FPiette Yes, that's why I was planning to have a separate thread constantly reading the StdIn.
@KodeZwerg Yes, I was planning to create a separate TUCI class to handle the communication
-
I'm converting my chess engine to Delphi. It's a console application that uses the UCI protocol. I'm use "writeln" to send text to the console and have a thread that simply uses "readln" to capture the input from the user. Everything works fine when it's run as a terminal application and I type in the commands. However, when I try to run it using a Chess GUI the communication doesn't happen. I've written a short app using DOScommand and it seems the communication isn't happening between the two applications. What am I missing? How do I capture the standard input sent from the other application? How do I write back my commands to the standard output so it can be processed by the other application (i.e., the chess GUI)?
Thanks, Steve
-
3 minutes ago, Der schöne Günther said:Function arguments are always evaluated, then passed into the function. This "IfThen" (which I have never seen before), is just a regular function. The compiler has no knowledge that there is no need to evaluate the other arguments if the first one results to False.
That makes sense. I learn something new every day!
Thanks,
Steve
-
The following code causes an AV:
type TFoo = class private fName: string; public property Name: string read fName write fName; end; TForm1 = class(TForm) procedure FormCreate(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation uses StrUtils; {$R *.dfm} procedure TForm1.FormCreate(Sender: TObject); var Foo: TFoo; begin Foo := nil; Form1.Caption := IfThen(assigned(Foo), Foo.Name, ''); end;
The line that cause the AV is the one with the "IfThen" statement. I would have thought this would set the Caption to '' if Foo was not assigned but instead I get an AV. This implies both the True and False expressions are evaluated but I can't see why. Am I missing something obvious? The project is attached.
Delphi 11.1
Any insights appreciated.
Steve
-
@corneliusdavid many thanks! I didn't know that only the 32 bit runtime was needed. Everything seems to work perfectly!
-
Strangely, on my old computer running Delphi 10.4 I only had a win32 version of DesignIDE.dcp yet TChromeTabs installed fine on win64 via GetIt
-
@corneliusdavid & @Fr0sT.Brutal — Many thanks!
I managed to compile for 32 bit but not for 64 bit. It needs "DesignIDE.dcp" which is available in the following location:
C:\Program Files (x86)\Embarcadero\Studio\22.0\lib\win32\debug\designide.dcp
It seems it's not available for Delphi 11.1 64 bit — any ideas?
-
Has anyone been able to install TChromeTabs for Delphi 11.1? It's missing a *.groupproj file for Delphi 11. Any steps would be appreciated.
It was in GetIt but isn't anymore.
Thanks, Steve
-
-
16 hours ago, Remy Lebeau said:Is there an error message? And you didn't answer my question - which version of Delphi are you using? Nothing in the code you have shown should be accessing any monitor-specific functionality, AFAIK.
Yes.
Hi Remy,
I'm using Delphi 10.4.2.
We have been unsuccessful in replicating the problem, although I did see it for myself on a Zoom call. At this point I'm going to move on and class it as a strange setup issue.
Thanks — Steve
-
2 minutes ago, Anders Melander said:So you haven't tried to reproduce the problem with two monitors...?
Yes.
If you had looked at the source you would have seen that TControl.ClientToScreen calls TControl.GetClientOrigin which ends up calling Winapi.Windows.ClientToScreen(Handle, Result);
The ClientToScreen API function returns the coordinates relative to the top left corner of the primary monitor, which is what you'd want.
I don't have an extra monitor but a colleague has one so we're trying to reproduce. It seem the problem occurs in a configuration of two monitors above the main screen / laptop screen.
App Builder & Blazor
in General Help
Posted
That gives me hope