Mark Williams

Unit2.pas Unit2.dfm I have made slight changes. Both of my own functions are now called with the same parameters. The strUtils one works as expected. The AnsiStrings one reports -1 Thanks

Thanks to Stano the function now compiles. However, I cannot get the AnsiStrings function to work as I would expect ie in the same way as the strUtils unit. The code is: {Ansitrings:} Function FindWordInText(Const Text:PAnsiChar; Const FindText:AnsiString; index:integer):Integer; {StrUtils:} Function FindWordInText(Const Text:PWideChar; Const FindText:AnsiString; index:integer):Integer; var {AnsiStrings:} P:AnsiChar; {StrUtils} P:PWideChar; Size:word; Options:TStringSearchOptions; begin Size := length(text); //Buffer := StrAlloc(Size+1); Options:=[soDown]; P := {System.AnsiStrings.}SearchBuf(text, Size , 0, index, FindText, options); if P <> nil then Result:=P-text; end; StrUtils function correctly returns the position of a word within the text, AnsiStrings function always returns -1. I assume it is to do with the difference between PWideChar and PAnsiChar, but how do I handle that please within this function?

Sorry should have spotted that myself, although the help file in the StrUtils unit only refers to the functuion being deprecated for C++. I am now getting an "Ambiguous overloaded call to SearchBuf" error. I am calling SearchBuf in a functions declared as follows: Function FindWordInText(Const Text:PAnsiChar; Const FindText:AnsiString; caseSens, WholeW: boolean; index:integer):Integer; var P:PAnsiChar; Size:word; Options:TStringSearchOptions; begin {irrelevant code removed} P := SearchBuf(text, Size , 0, index, FindText, options); end; After changing my reference to strUtils in uses to AnsiStrings this would not compile. Reason being that TStringSearchOptions is in strUtils. So I also added StrUtils back in to my uses after AnsiStrings. As soon as I did so, I get the ambiguous error. The parameters passed into my function are correct for the SearchBuf function in AnsiStrings unit. I also get the same error if I add the AnsiStrings unit after StrUtils in my uses clause. If I change my functions parameters as follows: Function FindWordInText(Const Text:PWideChar; Const FindText:AnsiString; caseSens, WholeW: boolean; index:integer):Integer; var P:PWideChar; Size:word; Options:TStringSearchOptions; begin P := SearchBuf(text, Size , 0, index, FindText, options); end; It compiles and executes fine. Presumably, it is calling the StrUtils function. But why am I getting an ambiguous error with PAnsiChar as a parameter, but not PWideChar?

I am using Searchbuf from SysUtils. I am getting the above warning. Often when the compiler warns that a function is deprecated it points you to a new function that performs the same or advanced role. Not in this case. Anyone know what if anything has replaced SearchBuf?

Yes please

I have cloned the repository, but can find no reference to 2009. You mention cloning the "whole" repository. I guess I am not doing that. How do you get the whole repository from Github?

Because there are so many changes and the issue is random, I have been trying to avoid a bit by bit reversal, but it is looking as if I have no alternative!

Double-checked all tree code. The tree data does not link objects. They reference objectlists, but the tree data merely references an index to the objects in the objectlist. I've double-checked that I'm the object referenced by the index stored in tree data exists before attempting to refer to it. All that seems okay. I've also wrapped all freenode event code in try except. Still at a loss as to what is causing the problem.

I can only find as far back as 6.2.0, which does not appear to support Delphi 5

Googled Github Repository. No VTV in there. Any idea where I might find it I'll double check all tree data usage. Pretty sure there is nothing there that should cause problem, but could be wrong.

I have a very old project written in Delphi 5. Upgrade to RAD Studio not really possible at the moment due to work commitments. The project uses VirtualTreeView version 4.0.15 and includes various TVirtualStringTrees on various forms including the main form. I have made numerous small changes to the project in the last few weeks. I am now randomly getting errors when closing forms (including those which do not include TVirtualStringTree. The error arises from the freeing if tree nodes. No clue in the error report as to which treeview. I have tried to replicate the error by repeating the same steps to no avail. It is quite random. When the error arises the app has to be restarted. I assume the error is caused by some change I have made somewhere along the line, but I can't think what. I am trying to find a later version of VirtualTreeView for Delphi 5 in the hope that may fix the problem. Does anyone know what was the last version for D5 and where I can get it from? Also, can anyone think what may be causing random node freeing bugs in this way? I appreciate there could be many causes and I have provided hardly any info! But if anyone can think of anything that might be the cause it would be appreciated. Pulling out what little hair I have left!

I'm using PDevMode to change printer settings. Printer.GetPrinter(Device, Driver, Port, hDMode); if (hDMode<>0) then begin pDMode := GlobalLock(hDMode); if pDMode <> nil then begin with pdMode^ do begin dmFields := DM_DEFAULTSOURCE; dmDefaultSource := ToBin; dmFields := dmFields or DM_PAPERSIZE; dmPaperSize := DMPAPER_A4; // Letter, 8-1/2 by 11 inches dmFields := dmFields or DM_PRINTQUALITY or DM_YRESOLUTION; if BestQuality then begin dmPrintQuality := LoWord(High_Quality); dmYResolution:=HiWord(High_Quality); end else begin dmPrintQuality := LoWord(Med_Quality); dmYResolution:=HiWord(Med_Quality); end; dmFields := dmFields or DM_DUPLEX; dmDuplex := DMDUP_VERTICAL; dmFields := dmFields or DM_COPIES; dmCopies := Copies; end; GlobalunLock(hDMode); This works fine if you only want to print one document or many documents with the exact same settings. But I am printing various documents in a loop and different document get printed at different qualities, with different nos of copies and to different bins. The problem is that once set the settings are saved and calling the above function does not change the settings for the new document. One code example I found suggests the following: Printer.GetPrinter(Device, Driver, Port, hDevmode); {force reset of devmode} Printer.SetPrinter(Device, Driver, Port, 0); Printer.GetPrinter(Device, Driver, Port, hDevmode); However, I then get a "Printer selected is not valid" error immediately I call Printer.BeginDoc. I'm not sure what else to do. Have tried Printer.Refresh which is no help. I've come up with a clunky temporary solution which is to change the PrinterIndex immediately after Printer.EndDoc and then set it back to the desired printer. It works in clearing the settings, but I'm sure it is not the best way to do this!

Thanks. I didn't read the help file properly!

I create/open a TFileStream in non-exclusive mode with the following code: if not FileExists(FileName) then //have to create it first and close it otherwise the share mode does not work!! begin Result := TFileStream.Create(FileName, fmCreate, fmShareExclusive); Result.free; end; Result := TFileStream.Create(FileName, fmOpenReadWrite, fmShareDenyNone); By my reckoning I should be able to open the file in read only mode: fs := TFileStream.Create(FileName, fmOpenRead, fmShareDenyNone); But it throws up an EFOpenError ie file in use by another process. I have looked online and found old posts which suggest that the share modes do not function for fmCreate mode ie always created exclusively and that is why I create, then close and then open. There was a post around 2010 which suggested the issue had been reported to Embarcadero and that it had been closed as fixed. Couldnt find anything much later than this. However as you can see , my problem is not with fmCreate, it is with fmOpenReadWrite. is there a bug with TFileStream or am I handling this in the wrong way? If there is a bug, does anyone know a work around?

It has taken me an age to get back around to this, but I have finally uncovered the problem. It was not with FireDAC but my code.