Anders Melander

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.

Yes, the Printer global TPrinter instance is a singleton and AFAIK it is not thread safe. However I can't see why it should be a problem for each thread to create their own TPrinter instance and use that to print. The print job context wrapped by TPrinter is not a singleton and the target print device does not necessarily represent a single physical device. procedure TMyThread.Execute; var Printer: TPrinter; begin ... Printer := TPrinter.Create; try ... while (not Terminated) do begin ... Printer.BeginDoc; try ... finally Printer.EndDoc; end; ... end; finally Printer.Free; end; end;

I don't know but don't you have the source code? It should be fairly easy to find out exactly what TIDMessage does if you just trace into LoadFromFile in the debugger.

It depends. Do either this: Foo := TFooBar.Create; try ... finally Foo.Free; end; or this: Foo := nil; try Foo := TFooBar.Create; ... finally Foo.Free; end;

Apparently they haven't discovered that you can .gitignore files? I think we must have different definitions of "least resistance"

No. You discussed it here:

Here you go: type // The interfaces are probably defined in your type library unless they are purely // for internal use within the application. IFoo = interface ['{922E28A3-0127-42DB-A394-2CFED29A5575}'] procedure DoFoo; safecall; end; IBar = interface ['{BECBDCE4-192C-48DC-9DC4-85DB92E01E9F}'] function GetFoo: IFoo; safecall; end; type // If you're using dual/dispatch/late bound/automation interfaces then use TAutoObject or // TAutoIntfObject as a base class instead. See the help. TFoo = class(TInterfacedObject, IFoo) private // IFoo procedure DoFoo; safecall; end; procedure TFoo.DoFoo; begin ShowMessage('Hello world'); end; type TBar = class(TInterfacedObject, IBar) private // IBar function GetFoo: IFoo; safecall; end; function TBar.GetFoo: IFoo; begin Result := TFoo.Create; end; ... procedure Test; var Bar: IBar; Foo: IFoo; begin Bar := TBar.Create; Foo := Bar.GetFoo; Foo.DoFoo; end; The principles hasn't changed since Delphi 5 and you're not going to save any time by not learning this stuff. I recommend you read this (old) one: http://www.techvanguards.com/stepbystep/comdelphi/

Yes, I agree. My point was that it's optional. safecall transforms hresult into exceptions which sometimes is exactly what you want and sometimes not.

Before you posted this the first hit on Google for "TdxfOutlookBar" was Q499568 Replacement for TdxfOutlookBar...

Make that: In that case your method can be declared "safecall".

Once again: As far as I can tell there's nothing special in the work flow your describe. It's perfectly normal to have a branch per ticket, to change branch several times a day, to get interrupted while you're working on something that hasn't yet been committed, etc. The problems with Git you describe (changes disappearing, etc) are not problems with Git but with the way you use it; It will not overwrite your uncommitted changes unless you force it to. It is unclear to me what benefits your tool provides. It sounds like the problems it solves are already handled by the existing GUI Git clients.

As I wrote you cannot compare a byte (ansichar) to 13 bytes (byte array) for equality. Since the size is different they will always be different, so what you're asking isn't making sense. Are you trying to determine if the byte array contains the ansichar? function Contains(const Bytes: TByteArray; c: AnsiChar): boolean; begin for var b in Bytes do if (b = Ord(c)) then Exit(True); Result := False; end;