giomach

I hadn't used any $A directives in the project, but I put in {$A4} as you suggested, and magically the number of records is 951. There are still other errors to fix, but I seem to be able to access the records now. Thank you very much for your help.

I've just tried all values from off to quad word several times and they are all giving 998. An hour ago, they were all giving 977 ... I can't make any sense of it. If we don't know what alignment D5 does, and can't find out how to make XE do the same, the only solution may be to extend the program with a procedure to export the datafile to a text file, compile and run on D5, then extend the program with a procedure to import from the textfile and run that on XE.

Adding filler: string [2] reduces the reported no of records in XE from 998 to 977, but this does not help, I'm still unable to retrieve them. I found that changing the XE compiler option "record field alignment" from byte to word also reduces the number to 977. But also no help. The option in D5 is a check-box named "aligned record fields", which is checked by default, and this was probably the setting when that file was produced.

Thanks, Holländer, but the program doesn't get as far as that. After it misreports the number of records, any further reading of data (by 'seek' and 'read') just produces rubbish (out of range, etc). I think I need to make it get the number of records correct before it can even separate the records, and I think that means some change to my definition of lexrec. Thanks Uwe. 951 records is correct, and that is what the program compiled in D5 reports. Compiled in XE, it reports 998 records, before going nuts. Some of the things I have tried in place of string32, like shortstring or array[1..32] of char, produce other wrong numbers of records.

I took an old program (Delphi 5) and tried to recompile and run it under XE. There was a data file, created under D5, which I tried to read in the recompiled XE program but it is misread — even the number of records comes out wrong (the correct number in 951). Here is a minimal example of the program source (the form is empty). It works perfectly when compiled in D5 under WinXP and run on the same data file. I'm also dropping the data file below. unit MorphAll; interface uses Forms, SysUtils, Dialogs; type TForm1 = class(TForm) procedure FormActivate(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.DFM} type valid_range = -1..5; string32 = string [32]; supp_rec = record flag: integer; case nform: integer of 1: (single: array [1..1] of string32); 2: (double: array [1..2] of string32); 3: (treble: array [1..3] of string32) end; normal = array [1..20] of integer; lexrec = record root_part: string32; case speech_part: valid_range of -1: (suppletive_type: supp_rec); 0: (nsupp_type: integer); 1,2,3,4,5: (normal_type: normal) end; lexfile = file of lexrec; var morphlex: lexfile; nooflexrecs: integer; procedure TForm1.FormActivate(Sender: TObject); begin assignfile (morphlex, 'MorphIr.dat'); reset (morphlex); nooflexrecs := System.FileSize (morphlex); ShowMessage ('Data file contains '+inttostr (nooflexrecs)+ ' records'); end; end. I suspect the trouble is the type declaration string[32]. When the data file was created (D5), this would have been an old-style string, and moreover the encoding would have been Windows 1252. How can I make XE interpret these strings correctly (if that is what is wrong)? MorphIr.dat

Many thanks!

Thanks Ioan, that worked great. My next question to all 🙂 Many of the files I'll be looking for will not exist on the server. Is there a way to test for the existence of a remote file without actually trying to download it, and importantly would that be quicker than what I'm doing, which is trying to download and checking whether the size is non-zero? (I will treat a non-existing remote file and an existing file of zero size in the same way, so I don't need to distinguish those two cases.)

Thanks for both suggestions, but in both cases it looks like a steep learning curve would be involved! Lots of technical jargon to be deciphered! Actually, I think TMediaPlayer can do all that I need. I now realise that it can handle WAV as well as MP3, and that it will extract a clip, given start and end times. It's just a matter of finding out how to do it all. I intend adding these sound files to a Windows VCL app which I distribute, and I have some decisions to make: store the sounds locally or remotely; store them as WAV or MP3; store them as many separate files or extract them on-the-fly from longer files. I'll just have to try them all and see what works best.

I'm likely to have further elementary questions about IdHTTP, so if someone can recommend a reference on using it to access REST in the context of Delphi (and preferably a written reference rather than a video), that might save time and bother. Meanwhile, here's my first simple question. The Delphi statement s := IdHTTP1.Get (url+filename); where s is a string successfully fetches data from a remote server. But when the remote file is actually a sound file, having it in a string is not much use to me. How can I get it into a sound file on my local machine? Thanks in advance for your advice.

Thank you, Remy. Yes, those two design-time packages were not present on the list of Installed Packages, so I added them, and everything seems to be in order again. When I was writing the "old" program some years ago, I had to update Indy (from 10.1.1. to 10.6.2) and these packages were on the list then, and I have no idea how they could have been removed in the interim.

Windows 10, Delphi XE It's some years since I used TIdHTTP in a program. Now I'm trying to use it again, in new program. I don't remember whether in my old program I simply added IdHTTP to the "uses" statement, but when I do that in the new program I get F1026 File not found: 'IdHTTP.dcu', as well as Cannot resolve unit name 'IdHTTP' at line 38. Perhaps in the old program I had placed some control on the form, but now I don't see anything on the Tool Palette that mentions TIdHTTP. On going back to my old program and trying to open the source (which is unchanged and has "IdHTTP" in its "uses"), Delphi now says Error reading Form1 - Class TIdHTTP not found and the form is not created. What could be causing IdHTTP to go missing?

Windows 10, Delphi XE I want to play a short sound file in response to clicking a button (var SoundButton:TBitBtn). I have two ways which work, but neither is fully satisfactory. Method 1: with a WAV file — fast, but needs a lot of disk space to store the files procedure TFocalForm.SoundButtonClick(Sender: TObject); // 2024/03/20 for .WAV var ms: TMemoryStream; begin ms := TMemoryStream.Create; try ms.LoadFromFile (SoundFileName); ms.Position := 0; sndPlaySound (ms.Memory, (SND_ASYNC or SND_MEMORY)) finally ms.Free end end; Method 2: with a MP3 file (var SoundPlayer: TMediaPlayer) — saves disk space but there is a delay of several seconds before the sound starts procedure TFocalForm.SoundButtonClick(Sender: TObject); // 2024/03/20 for .MP3 begin SoundPlayer.Close; SoundPlayer.Filename := SoundFileName; SoundPlayer.Open; SoundPlayer.Play; end; Is there a better way? And a related question: these sound clips — there could be hundreds of thousands of them eventually — are extracted from a smaller number of larger sound files. Is there an interface to play such a clip from the larger file, by supplying start and finish times? And if there is, would it be any advantage at runtime? Thanks for your suggestions.

Many thanks, aehimself. As soon as I cleared the icon cache, the desktop icon changed to the one I wanted, without even having to recreate the shortcut. That was indeed the problem.

Using Delphi XE Update 1 (2010) I'm trying to set the application icon to one I have created, and have this icon appear on a desktop shortcut to the application. The first screenshot shows the .dpr file. I don't know why both *.res and *.dres are present, they just appear and disappear. The second screenshot shows that I have no "additional" icons in the application. The *.dres has disappeared when I removed a previous additional icon. The third screenshot shows setting the MAINICON. I would prefer to choose the 256x256 79KB one, but this gives "out of system resources" — but that's a separate problem. So I choose the 48x48 10KB version, and the fourth screenshot shows it loaded. I now rebuild the application. The fifth screenshot shows Resource Hacker confirming that this is the only icon in the application. The sixth screenshot shows another utility also confirming it. I now create a desktop shortcut to the application. The seventh screenshot shows the result — Delphi XE's default icon on the desktop instead of the one I want. I know I can tweak the shortcut to get the icon I want, but this is no use. I need this icon automatically on the shortcut created by the installation of the application on other machines. Any help welcome.

TDictionary has now solved the problem — but not exactly in the way I expected. To summarize, I have two programs — a "setup" program which produces data in the form of two stringlists which correspond item-by-item; and a "user" program which reads this data and repeatedly looks up a string in the first list and extracts the corresponding string from the second list. This works perfectly well, but in raising this thread I sought to improve the speed of TStringList.IndexOf in the user program by sorting the first list in the setup program before exporting it. To do this, while keeping the two lists aligned, I combined them into a single "name=value" stringlist, which I custom-sorted on the "name" and exported to the user program. But in the user program, searching the combined stringlist, IndexOfName still used the slow linear search. Next, in the user program, it would have been logical to re-separate the combined list into two stringlists, but instead I chose to skip that avenue, and to read the combined list into TDictionary. Access from there works and is very fast. I had considered using TDictionary in the setup program, but it has no SaveToFile member. In fact, a TStringList seems to be one of the few things that can be passed from one program to another via a file. So the TDictionary processing has to take place in the user program, and there is no point in having the data sorted in the setup program. That is, I had to add processing into the user program in order to speed it up! Thank you all for your contributions to the solution, including those whose suggestions I did not get around to trying.