Ian Branch

P.S. I'm loving the Type inference...

Hi Team, Thank you for your responses. David - What is the issue with smallint?? Remy - Thank you for the clarifications.. The "array" and "of" have the squiggly red line under them. For array - 'Expression expected but 'ARRAY' found'. And, for of - 'Type identifier expected'. Regards, Ian

GoTo - Another case of the right tool for the right job... 😉

I generally do, just hadn't got around to it yet.

Hi Team, OK. Got it sorted. Thank you very much to all for your patience and education. To reflect on what David said.. Why?? I mean, is this just fancy code for the sake of it?? No offence David. Ian

Ok. I did that... private { Private declarations } FsMode: string; FiAlbum: integer; FsTrack: string; public { Public declarations } // property sMode: string read FsMode write FsMode; // property iAlbum: integer read FiAlbum write FiAlbum; // property sTrack: string read FsTrack write FsTrack; constructor TTracksAddEditForm.Create(AOwner: TComponent; const AsMode: string; AiAlbum: integer; const AsTrack: string); protected procedure CreateParams(var Params: TCreateParams); override; end; var TracksAddEditForm: TTracksAddEditForm; implementation {$R *.dfm} constructor TTracksAddEditForm.Create(AOwner: TComponent; const AsMode: string; AiAlbum: integer; const AsTrack: string); begin inherited Create(AOwner); FsMode := AsMode; FiAlbum := AiAlbum; FsTrack := AsTrack; end; But it still doesn't like it. 😞

Hi Dalija, Where does that go and why? Ian

Hi David, I'm sure it is when you know how. 🙂 I am open to education on this matter, just as I was/am on anything I haven't used. Ian

All, Thank you All for your contributions, in particular Dalija for your clear explanations. Appreciated. Response to some questions.. 1. Using Show? Only during development. It is now a ShowModal inside a Try-finally-end. 2. Empty parameters. Yes in either case one of the parameters may be empty. 3. Using a constructor. Never knowingly done so. I tried Dalija's constructor but it gives me an E@065 Unsatisfied forward or external declaration: 'TTracksAddEditForm.Create'. Not an issue, I don't believe I will go that route. Interesting result using Dalija's code with just the 'write'. I couldn't read the values in the created form. If I changed the write to read, I could read the values in the second form but not write to them in the calling form. Conclusion, I need both read and write & no Getters/Setters. 🙂 Regards and thanks All again. Another small gap filled in the vast emptiness of my knowledge. Ian

Hi Team, To put further context, this is what I have.. In the Calling Form.. procedure TAudioForm.btnEditTrackClick(Sender: TObject); begin TracksAddEditForm := TTracksAddEditForm.Create(Self); TracksAddEditForm.sMode := 'Edit'; TracksAddEditForm.iAlbum := Albums.FieldByName('Index').AsInteger; TracksAddEditForm.sTrack := TracksView.FieldByName('Title').AsString; TracksAddEditForm.Show; end; procedure TAudioForm.btnInsertTrackClick(Sender: TObject); begin TracksAddEditForm := TTracksAddEditForm.Create(Self); TracksAddEditForm.sMode := 'Insert'; TracksAddEditForm.iAlbum := Albums.FieldByName('Index').AsInteger; TracksAddEditForm.sTrack := TracksView.FieldByName('Title').AsString; TracksAddEditForm.Show; end; In the Created form.. private { Private declarations } FsMode: string; FiAlbum: integer; FsTrack: string; function GetsMode: string; procedure SetsMode(const value: string); function GetiAlbum: integer; procedure SetiAlbum(const value: integer); function GetsTrack: string; procedure SetsTrack(const value: string); public { Public declarations } property sMode: string read GetsMode write SetsMode; property iAlbum: integer read GetiAlbum write SetiAlbum; property sTrack: string read GetsTrack write SetsTrack; end; var TracksAddEditForm: TTracksAddEditForm; implementation {$R *.dfm} function TTracksAddEditForm.GetsMode: string; begin result := FsMode; end; procedure TTracksAddEditForm.SetsMode(const value: string); begin FsMode := value; end; function TTracksAddEditForm.GetiAlbum: integer; begin result := FiAlbum; end; procedure TTracksAddEditForm.SetiAlbum(const value: integer); begin FiAlbum := value; end; function TTracksAddEditForm.GetsTrack: string; begin result := FsTrack; end; procedure TTracksAddEditForm.SetsTrack(const value: string); begin FsTrack := value; end; Now, this all works fine, the relevant information is available in the created form and everything happens as it should/is desired. I created this by just emulating what I did once before in another App.. IIUC, the code in the created form, TracksAddEditForm, is simply making the properties available to the calling/creating form by making them properties of TracksAddEditForm. OK. So, do I need both Get & Set if the information is only going one way? Or is that the necessary structure. Is it the Get or the Set that is being 'populated' from the calling/creating form? To answer a concerned expressed - Speed is not an issue. I guess I should ask, is there a better way to do this? Regards & TIA, Ian

Thanks Team, In my case it is passing a value to a form about to be created. Ian

Tks Martin, I'm sure it was working a couple of weeks ago. It is one I visit regularly. I thought it might have been down for maintenance or something. Oh well. Another valuable resource seems to have bit the dust.. 😞

Hi Team, In a simple Win32 App, when might ExtractFilePath(Application.ExeName) not be the same as TDirectory.GetCurrentDirectory if called in the Main Form?? Regards & TIA, Ian

Hi Guys, Thank you for your inputs. I wasn't trying to solve any particular problem, just curious. Ian

Tks Lajos, Neither apply in my situation. Ian

Hi Team, D11.2 patch 1, 32bit VCL Apps. I have this bit of legacy code.. ... // r := FindFirst(sTempFilesPath + '*.*', FaAnyfile, DirInfo); // 0 if files are found. // while r = 0 do begin if ((DirInfo.Attr and FaDirectory <> FaDirectory) and (DirInfo.Attr and FaVolumeId <> FaVolumeID)) then if DeleteFile(pChar(sTempFilesPath + DirInfo.Name)) = false then Memo1.Lines.Add(' Unable to delete file ' + sTempFilesPath + DirInfo.Name + '!') else Memo1.Lines.Add(' File ' + sTempFilesPath + DirInfo.Name + ' successfully deleted.'); // r := FindNext(DirInfo); // end; // ... ... D11.2 is telling me FaVolumeId is deprecated.. To what? What replaces it? Alternatively, how should the above be now written? Regards & TIA Ian

Hi Nigel, Correct, the test is to ensure that sTempFilesPath actually has something in it. I suppose I could just as easily have used sTempFilesPath.IsEmpty. Ian

Hi Team, After further study it cleaned own to this.. // // Delete all files in the Server Temp Files Path. // if Trim(sTempFilesPath) <> '' then begin // DBE1.Close; // aFilenames := TDirectory.GetFiles(sTempFilesPath); // Memo1.Lines.Add('Now deleting ' + Length(aFilenames).ToString + ' files found in the Database Temp Files Drive/Directory.'); // for FileName in aFileNames do begin // if DeleteFile(FileName) = False then Memo1.Lines.Add(' Unable to delete file ' + FileName + '!') else Memo1.Lines.Add(' File ' + FileName + ' successfully deleted.'); // end; // Memo1.Lines.Add('The Database Temp Files Drive/Directory has been cleared.'); Memo1.Lines.Add(' '); // end; // Tks to all. Regards, Ian

Hi Peter, Tks for the pointer. Haven't used those before. I declared.. var Path: string; Filenames: TArray<string>; i: Integer; Then coded.. // Filenames := TDirectory.GetFiles(sTempFilesPath); // Memo1.Lines.Add('Now deleting ' + Length(Filenames).ToString + ' files found in the Database Temp Files Drive/Directory.'); // for i := 0 to Length(Filenames) - 1 do begin if DeleteFile(PChar(sTempFilesPath + Filenames[i])) = False then Memo1.Lines.Add(' Unable to delete file ' + sTempFilesPath + Filenames[i] + '!') else Memo1.Lines.Add(' File ' + sTempFilesPath + Filenames[i] + ' successfully deleted.'); // next; end; // Memo1.Lines.Add('The Database Temp Files Drive/Directory has been cleared.'); Memo1.Lines.Add(' '); // I used DeleteFile rather than TFile.Delete as the latter did not give me a boolean response for the Memo lines. Regards, Ian

Hi Team, I have used a TStaticText but the Font|Colour property doesn't do anything. 😞 Is there a fix for this?? If not, why is the property there?? Ian

I created a new form with nothing but a TStaticText on it. I set the VCL Style to Windows 11 Polar Light. With StyleElements seFont & seClient off, and transparent off, I get the green text but at run time the text background is the standard windows background. If I turn Transparent on the color disappears at design & run time. If I turn seClient on, the color stays at design time but disappears at run time. If I leave seClient off and turn seFont on, the color stays at design and run time but I get the standard windows background. I changed to one of the standard VCL Styles and get the same results. 😞 Perhaps a bug with TStaticText and VCL Styles?? Oh well. Back to TLabel and flickering... 😞

It was on. I turned it off and the font color shows at design time but not at run time.

Hi Peter, It wasn't set. The color doesn't show at design time either. 😞 Ian

VCL Styles.

I would concur with creating your own Repository. Also, please don't leave us purely VCL programmers behind. 🙂