Anders Melander

Why do you think that?

Seriously?

I think Apples revenue speaks for itself. Even though they make some really nice hardware it's obviously overpriced.

It's been a while since I did any comparisons of Graphics32 and GDI+ but AFAIR in the few cases where GDI+ came close to Graphics32 it did so at the cost of quality - e.g. fewer anti-aliasing levels or anti-aliasing via oversampling. To be fair the performance of Graphics32 comes at the cost of versatility since it only does 32-bit images. Graphics32 also has a steep learning curve. In those cases where GDI+ has a feature missing from Graphics32 I believe one can use GDI+ to draw on a Graphics32 bitmap via the bitmap handle.

The iterators were David's code and was just part of the test bench. As long as every solution uses the same test bench code then that doesn't matter much but when some solutions then replaces the test bench code to optimize the solution that invalidates the comparison.

Generally Graphics32 does everything faster but specifically you will need to clarify what operations you're asking about to get a usable answer.

While I don't question the timings I don't think these latest benchmarks are fair; The goalposts have been moved. It seems the first solutions were aiming at optimizing conversion of a single hex digit and the later ones are optimized for strings. Some have had the iterators replaced by classic for and some haven't.

That was my thought too but then again, apart from the challenge of it, it's kinda pointless trying to squeeze every last microsecond out of an ASCII HEX to ASCII BIN conversion. It would be more relevant for HEX to binary conversion. Maybe in this case. You can find plenty of examples out there which demonstrates that a LUT isn't always faster. For example: What's the fastest way to convert hex to integer in C++?

Refactor it into a generic unit. Save it in its own Git repository (or have all these utility units in a single repository). Reuse it as a Git submodule in the projects where I need it. Git submodules are a bit of a hassle but it's better than just copying units into other projects and then have to manually update each one every time you fix a bug or make an enhancement.

The config file helped for me One thing though: The conversion doesn't preserve the file encoding; The new file is written as ANSI even if the source file was UTF-8 encoded.

Yeah that's a bit unfortunate. The button is there to remind me to implement it - and it's disabled simply because I never got around to that. Same with the Import from and Save to Excel buttons. I take it your would expect to be able to import CSV in the same format as the exported CSV? I.e.: Module;Item;ItemType;Property;Source;Translation_0;...;Translation_n The original aim was to be able to map arbitrary CSV columns to the localization columns, but that's more work than I have to spare right now.

Looking into my crystal ball I see that in a few years Microsoft will introduce something even better and we will be left with yet another UI layer. One can hope that they've learned from their mistakes but their track record isn't too great.

Ah yes. Shouldn't TServerServiceMethod be declared like this then: type TServerServiceMethod = function(Sender: TObject; const ClientIdent: TkbmMWClientIdentity; const Args:array of Variant): variant of object; (add "of object") Also I think you need to call it like this: var ServiceMethod: TMethod; begin ServiceMethod.Data := Self; ServiceMethod.Code := MethodAddress(Func); TServerServiceMethod(ServiceMethod)(Self, ClientIdent, Args); end;

I think you'll have to ask @Kim Madsen for help on this one. I would imagine that it's supposed to work with 64-bit but since I don't have the source I can't tell.

I haven't participated since Pulsar (I think that ended up as XE2) so I don't know how it's done these days. Back then pretty much everything was already written in stone at the time the field tests started so you could really only contribute with bug reports. In the beginning (up until around D9 (and please forget D8)) the field tests started much earlier (and ran longer) so there was a much better chance of influencing what ended up shipping. Regardless, if they're aiming for improved FP performance it would make sense to get early feedback from those to whom it actually matters.

Lower your expectations (if you have any). Sign up for the beta. Please!

Strange. Could be caused by a previous stack or heap corruption, maybe in the calling method. Or it could simply be a compiler bug. I don't think it's one that I've heard of though. If it's not evident, looking at the source, where the value comes from you can try to trace through the assembler in the CPU view to determine it. Also make sure to do a full build to ensure that there isn't a dcu mismatch somewhere.

Run it through the debugger: Set a break point on the line and "step into" the assignment. Make sure you compile with debug dcus.

procedure TMyForm.ButtonScrollPageUp(Sender: TObject); begin PostMessage(MyGrid.Handle, WM_SCROLL, SB_PAGEUP, 0); end; procedure TMyForm.ButtonScrollPageDown(Sender: TObject); begin PostMessage(MyGrid.Handle, WM_SCROLL, SB_PAGEDOWN, 0); end;

The Graphics32 scrollbar can be used as inspiration or a starting point: https://github.com/graphics32/graphics32/blob/master/Source/GR32_RangeBars.pas

He Who Must Not Be Named

Funny. I got booted too for suggesting he should stop posting about his non-delphi related pet projects. I guess that group wasn't big enough for both our egos Can't say I miss it much.

I don't think there's a widely used convention for that. I would just name it "Radio".

There are a few issues with your code and a few things that could be improved. 1) A member function has a hidden "self" parameter so in reality the signature of the MakeSine function you have declared looks like this: function MakeSine(const [ref] Self: TRadio; handle: HSTREAM; buffer: Pointer; Alength: DWORD; user: Pointer): DWORD; stdcall; If you want MakeSine declared as a member function then you need to declare it as a static class method: type TRadio = record ... class function MakeSine(handle: HSTREAM; buffer: Pointer; Alength: DWORD; user: Pointer): DWORD; stdcall; static; end; but then you lose the reference to self and can't access the member variables inside the method. I'm guessing that the user parameter is for passing context to the callback and if so you can achieve the same with an extra function: type TRadio = record ... private function DoMakeSine(handle: HSTREAM; buffer: Pointer; Alength: DWORD): DWORD; public class function MakeSine(handle: HSTREAM; buffer: Pointer; Alength: DWORD; user: Pointer): DWORD; stdcall; static; end; class function TRadio.MakeSine(handle: HSTREAM; buffer: Pointer; Alength: DWORD; user: Pointer): DWORD; begin Result := TRadioPointer(user).DoMakeSine(handle, buffer, Alength); end; function TRadio.DoMakeSine(handle: HSTREAM; buffer: Pointer; Alength: DWORD): DWORD; begin ... end; begin // Pass TRadio pointer as the "user" parameter resultValue := BASS_StreamCreate(cSAMPLE_RATE, 2, 0, @TRadio.MakeSine, PRadio); end 2) The convention would be to name your TRadio pointer type "PRadio" type TRadio = record ... end; PRadio = ^TRadio; 3) You don't need to deference typed complex pointer types with ^ PRadio^.MakeSine // standard Pascal PRadio.MakeSine // allowed in Delphi

Then you are already able to answer your own question. If your assumption is "possibly unsafe" then working on that assumption is not "the safest thing". You're contradicting yourself. You are never going to be able to handle every possible scenario. I suggest you create a set of test files, both valid and invalid. Make sure you can handle those but code defensively under the assumption that there are cases you don't know of yet.