Remy Lebeau

That is because IDLIST is an array (of integers), but you are trying to read it as a string. jso.GetValue('IDLIST') will return a TJSONValue pointer to a TJSONArray, which does not implement the Value() method, so it returns a blank string. You need to type-cast the TJSONValue to TJSONArray and enumerate its elements, eg: var jso: TJsonObject; jsa: TJSONArray; s, RetIDList: string; i: Integer; begin s := '{"RESULT":200, "IDLIST":[1,2,3,4,5]}'; jso := TJsonObject.ParseJSONValue(s) as TJsonObject; if jso <> nil then try ... RetIDList := ''; jsa := jso.GetValue('IDLIST') as TJSONArray; if jsa <> nil then begin if jsa.Count > 0 then begin RetIDList := jsa[0].Value; for i := 1 to jsa.Count-1 do RetIDList := RetIDList + ',' + jsa[i].Value; end; end; ... finally jso.Free; end; end;

C++ supports abstract classes. But abstract classes in C++ can't be used in all contexts that Delphi supports them. Also, not all of the empty methods are for abstract support, they are simply placeholders to allow descendants to hook into strategic places if they want to.

FreePascal/Lazarus's RTL/LCL frameworks are fairly API-equivalent to Delphi's RTL/VCL, about on par with Delphi 7-ish, with a few 2009+ features thrown in (UnicodeString, etc). So, if you have something already working in VCL, it will likely port as-is (or close to it) to Lazarus.

I miss the old newsgroups 😢 None of the newer web-based forums have really matched up to them, in terms of usability, monitoring, organization. It is just not the same.

My plan for Indy 11 many years ago was very different than the current plan. Originally, Indy 11 was going to be for a bunch of new features I was working on. Then a few years ago, we decided to make Indy 11 be just a maintenance release instead to cleanup the existing codebase (drop old compilers, cleanup ifdefs, etc), and push back new features to Indy 12. The "Restructure" branch currently in the GitHub repo is what will eventually become Indy 11. The majority of the work is already done, it just needs to be brought up-to-date with the latest master branch, rebranded, validate everything builds with the new folder/naming structures, etc.

But the naming of the DCP would change, and that would break existing projects. At the very least, I would have to issue an advisory and document that any Indy upgrades made past X release would require project updates to continue using Indy. I was waiting until Indy 11 to make that change, since I'm restructuring the packages anyway.

The code I presented is only handling 1 request/response at a time, per the documented flow chart. If there are multiple messages involved in a single transaction, then of course you will have to adjust the code to account for that. In the part where it says "use ReceivedText as needed...", you would have to actually look at the message data, and if it is INSERT CARD then progress to the next state and act accordingly to continue the transaction, not go back to the stIdle state until the transaction is finished. I have posted examples of that MANY times before, in many different forums. Should not be hard to find with some searching around. The best way to handle this is to implement a per-client thread-safe queue for each TIdContext, then your UI thread can push data into the queue of the desired client as needed, and the server's OnExecute event can send queued data for the calling TIdContext when it is safe to do so.

Are you SURE your entire process just terminates immediately when exit() is called, and you are not simply failing to catch an exception that causes your main thread to end? Have you wrapped the Python4Delphi code in a try/except block? I am not familiar with Python4Delphi, but after a quick look through its source code, it appears like it might catch a Python SystemExit exception and raise a Delphi-style EPySystemExit exception into user code. Not sure about that, though. Have you tried catching EPySystemExit?

WinInet supports both HTTP and HTTPS. InternetReadFile() works just fine with HTTPS resources.

I just looked at the Pull Request history, and I do see 2 requests that you had submitted and then closed. I don't think I ever saw them while they were open, otherwise I would have merged them. I have merged them now, and I will look into whether your changes should to be merged into other scripts.

I know. But since Indy has never used LIBSUFFIX, its package project names are suffixed, and so the dcp files are also suffixed. Well, they do use Indy inside some of their own tech, so they need a stable version to link against. But they are supposed to be using a private copy that is separate from the public copy they ship for users. That being said, it is a goal for Indy to eventually be phased out of the IDE releases and move into GetIt instead. But its complicated installation steps (more for C++ than Delphi) makes that difficult right now. I'm hoping to clean that up in Indy 11. True, most IDE releases don't ship with the latest Indy release available at the time. 10.4 did, though (which its Indy is already not the latest anymore).

Despite the title, that post is shaming Indy much more than it does TeeChart. And at the end, it says: I'm well aware of the issues you raised in that post. OK granted, the .bat scripts are a bit of a mess (I never use them myself, and the only reason they even exist is for supporting C++Builder). But the package names having hard-coded suffixes is not about being sloppy, it is about backwards compatibility. Indy still supports all the way back to Delphi 5 and even 4, which predate the LIBSUFFIX option. And by the time LIBSUFFIX actually became commonly used by component authors, it was too late to update Indy 10 without major breakages in existing user code. There is an open ticket to add LIBSUFFIX support to Indy, which is scheduled to be implemented in Indy 11, when support for old compilers will be dropped. Frankly, I don't know why TeeChart was ever referencing IndyProtocols.dcp in the first place, since Indy has NEVER used non-suffixed package names. IIRC, it might have been CodeGear/Embarcadero that did, at one time, strip off the suffixes in their private copies of Indy that shipped with the IDE. But the official version of Indy has ALWAYS used suffixed package names.

What's wrong with enumerating that folder? That is likely what the dialog is doing. Why do you expect there to be an API that provides that list? Not everything in a system UI has a dedicated API behind it.

As you should be, because THAT value you are assigning to dlgResult at THAT point in the code is indeed NOT being used, so it doesn't matter what value you assign to dlgResult. You are OVERWRITING that value afterwards, at "if FilterID1.Value.IsEmpty then dlgResult := False else dlgResult := True;" hence the compiler warning is correct. The compiler is not complaining that the dlgResult variable itself is not being used. It is complaining that the VALUE you are assigning to the dlgResult variable after FilterID1.Execute() exits is not used, so there is no point in assigning that value at all. I think you need to tweak this code a little. Try something more like this: dlgResult := FilterID1.Execute; if dlgResult then begin FilterValue := Trim(FilterID1.Value); dlgResult := not FilterValue.IsEmpty; end; if dlgResult then begin if not TryStrToInt(FilterValue, iJobNo) then begin MessageBeep(MB_ICONERROR); ShowMessage('An Invalid Job # has been entered!'); end else Break; end else ApplyFilter := False;

Why are you clearing the InputBuffer? If you are reading messages correctly, you should never need to do that. As I said earlier, since the ACK/NAK is only 1 byte, you should use ReadByte() instead of WaitFor(), eg: var b: Byte; b := IdTCPClient1.IOHandler.ReadByte; if b = $6 then // ACK begin // read POS's next message... end else if b = $15 then // NAK begin // failure of previous message you sent... end else begin // unexpected, do something... end; Personally, I would just get rid of the timer completely. Following the flow chart you posted earlier is easier when using blocking I/O operations with the IOHandler's ReadTimeout property, eg: var iTry: Integer; b, lrc: Byte; ReceivedText: string; procedure AddToMemo(const S: string); begin Memo1.SelStart := Memo1.GetTextLen; Memo1.SelLength := 0; Memo1.SelText := S + sLineBreak; end; begin iTry := 0; try IdTCPClient1.IOHandler.DefStringEncoding := IndyTextEncoding_8Bit; IdTCPClient1.IOHandler.ReadTimeout := 1000; repeat IdTCPClient1.IOHandler.Write(...); // send message to POS try b := IdTCPClient1.IOHandler.ReadByte; // wait for ACK/NAK except on E: EIdReadTimeout do begin Inc(iTry); if iTry < 3 then Continue; raise; end; end; if b <> $6 then // not ACK? begin Inc(iTry); if iTry < 3 then Continue; raise Exception.Create('No ACK received'); end; repeat // wait for message... ReceivedText := IdTCPClient1.IOHandler.WaitFor(#3, True, True); lrc := IdTCPClient1.IOHandler.ReadByte; AddToMemo('Received message:' + ReceivedText + Char(lrc)); if (ReceivedText is not valid) then begin IdTCPClient1.IOHandler.Write(Byte($15)); // send NAK Continue; // keep waiting... end; IdTCPClient1.IOHandler.Write(Byte($6)); // send ACK if (ReceivedText is HOLD message) then Continue; // keep waiting... // use ReceivedText as needed... Break; // all done... until False; until False; except on E: Exception do AddToMemo('ERROR! ' + E.Message); end; end; But, if you really want to use a separate timer, you should implement a state machine, eg: type TState = (stIdle, stSendingMsg, stWaitingForAck, stWaitingForMsg, stError); private iTry: Integer; CurrentMsg: string; State: TState; ... procedure TMyForm.AddToMemo(const S: string); begin Memo1.SelStart := Memo1.GetTextLen; Memo1.SelLength := 0; Memo1.SelText := S + sLineBreak; end; procedure TMyForm.IdTCPClient1Connected(Sender: TObject); begin IdTCPClient1.IOHandler.DefStringEncoding := IndyTextEncoding_8Bit; IdTCPClient1.IOHandler.ReadTimeout := 1000; State := stIdle; end; procedure TMyForm.DoSomething; begin iTry := 0; CurrentMsg := ...; State := stSendingMsg; Timer1.Interval := 10; Timer1.Enabled := True; end; procedure TMyForm.Timer1Timer(Sender: TObject); var b, lrc: Byte; ReceivedText: string; begin case State of stSendingMsg: begin try IdTCPClient1.IOHandler.Write(CurrentMsg); // send message to POS except on E: Exception do begin State := stError; Timer1.Enabled := False; AddToMemo('ERROR! ' + E.Message); Exit; end; end; State := stWaitingForAck: end; stWaitingForAck: begin try b := IdTCPClient1.IOHandler.ReadByte; // wait for ACK/NAK except on E: Exception do begin if E is EIdReadTimeout then begin Inc(iTry); if iTry < 3 then begin State := stSendingMsg; Exit; end; end; State := stError; Timer1.Enabled := False; AddToMemo('ERROR! ' + E.Message); Exit; end; end; if b <> $6 then // not ACK? begin Inc(iTry); if iTry < 3 then begin State := stSendingMsg; end else begin State := stError; Timer1.Enabled := False; AddToMemo('ERROR! No ACK received'); end; Exit; end; State := stWaitingForMsg; end; stWaitingForMsg: begin try ReceivedText := IdTCPClient1.IOHandler.WaitFor(#3, True, True); lrc := IdTCPClient1.IOHandler.ReadByte; except on E: Exception do begin State := stError; Timer1.Enabled := False; AddToMemo('ERROR! ' + E.Message); Exit; end; end; AddToMemo('Received message:' + ReceivedText + Char(lrc)); if (ReceivedText is not valid) then begin IdTCPClient1.IOHandler.Write(Byte($15)); // send NAK Exit; // keep waiting... end; IdTCPClient1.IOHandler.Write(Byte($6)); // send ACK if (ReceivedText is HOLD message) then Exit; // keep waiting... // use ReceivedText as needed... State := stIdle; Timer1.Enabled := False; end; end; end;

You need to upgrade to the latest Indy, yes. Indy 10 still supports Delphi/C++Builder 6.

It really depends on the format that the ESC/POS is expecting. It might be as simply as using TBitmap.SaveToStream() to save to a TBytesStream, and then using the stream's Bytes and Size properties. Or it may be more complex, like having to extract the individual pixels, like that other code is doing. You are going to have to provide more details about your particular situation.

Just on a side note, I probably would have used FormatDateTime() instead of DecodeDate() for for this, eg: uses ..., System.SysUtils; procedure TfAccounts.Button1Click(Sender: TObject); begin Label1.Caption := FormatDateTime('"Today is Day "d" of Month "m" of Year "yyyy', Now); end;

VCL's TMediaPlayer has an OnNotify event, which you can use to detect the end of playback. Load the video file paths into a list, start playing the 1st file, and use OnNotify to play the next file in the list, repeating until the list is finished.

The 2nd approach is correct - do the REST request in a background thread, leaving the UI thread free to manage the UI. You can update the UI to hide the progress screen when the thread is finished. We can't tell you why the progress screen is not displaying correctly, as you did not show a complete example. Maybe you are still blocking the UI thread in a way that we can't see. Are you able to display the screen if you disable the REST request? Please show a more complete example from start to finish.

And now we are drawing particles instead, my how far things have come

The nice thing about this one is that it already provides support for RAD Studio, you don't have to do anything extra for that. I don't know if this one supports RAD Studio by default or not.

No. GitHub provides an SVN interface. I was referring more to the fact that Indy doesn't use its own SVN server anymore now that it has migrated to GitHub: https://www.indyproject.org/2019/11/28/indy-svn-retiring-long-live-github/

Instructions can be found here: https://web.archive.org/web/20200925081341/http://ww2.indyproject.org/Sockets/Docs/Indy10Installation.EN.aspx (the live page on Indy's main website is offline right now). Indy doesn't use SVN anymore.

Yes. Is your project using VCL or FMX? VCL is compiled with OFF by default. FMX is compiled with ON by default. AFAIK, there is no IDE setting for Scoped Enums, they are controlled only via the {$SCOPEDENUMS} compiler directive. Should, yes. Indy's IdGlobal unit.