PeterBelow

Why should it? The Shift parameter is not a Var parameter so you just change the local value of it, not the one the caller passed. Even changing that (if you could) would not do what you think it should since it would not change the Windows-internal state of the modifier keys. And the WM_CHAR message for the tab key is already in the message queue anyway. Using keybd_event (in fact thats deprecated, you should use SendInput instead) puts a completely new Shift-Tab combination into the message queue, so you better set Key := 0 to abort processing of the 37 key. You should use virtual key codes instead of numeric values however, those make it clear which key you are processing here. VK_LEFT is much more readable than 37.

Nowhere in fact. Components are installed via design-time packages and those register their components when the package has been loaded, through calls to the Register procedure a unit in the package defines in its interface section (in fact several units can have such a procedure, though that is not recommended). The procedure contains calls to RegisterComponents that tells the IDE how the component class is named and on which page of the palette to display the associated icon. The installed design-time packages are listed in the registry.

Use the OnKeyPress event of the edit control. Like this: procedure TForm2.Edit1KeyPress(Sender: TObject; var Key: Char); begin if (Key = '+') and (GetKeyState(VK_ADD) < 0) then begin Key := #0; label1.Caption := 'VK_ADD'; end else label1.Caption := string.Empty; end; The GetKeyState API function allows you to check which key is currently down. The code above will let the '+' key of the normal keyboard add the character to the edit but block the numpad plus key input.

Have you tried running the code under an admin account? This may be a rights issue, since you are changing a setting that effects all users.

You cannot, since the pixel color in question depends on the background the image is rendered on. Just replace transparent pixels with a default color for the comparison, e.g. black.

The best way is to not have duplicate records in your query result in the first place. If you are using a SQL-supporting database just do not access the table directly (via TDBTable or analog), instead use a query component and give it a SELECT DISTINCT <columnlist> FROM <tablename> statement, optionally with more restrictions on the records to return (WHERE clause) and ordering. This way the result set will not contain duplicates in the first place. If the database you use does not support this kind of statement your best bet is to keep track of what you have already written to the file in an in-memory structure that supports quick lookup. You could concatenate all field values of a record into a string (basically the line you write to the text file) and store them into a TDictionary<string,byte>, using the byte part to keep a count of the duplicates you find. Depending on the number of records you have to process this may use too much memory, though. You could cut down on that by calculating a hash value from the string and storing the hash instead of the string. That is not completely failsafe, though, since different strings can result in the same hash value. You can deal with that by writing any such duplicate detected to separate file, which will end up with only few such records. When done with the task load that file into a stringlist, sort the list, and then do a final run over the record file and compare the lines read with the content of the stringlist, marking each match found there. If you end up with any unmarked items in the stringlist those are false duplicates and need to be added to the record file.

That is an old problem you also have at design-time: using ssPercent each change of a column width recalculates all column widths, including the one you just changed, so you end up with a value different from what you just entered. The algorithm used is faulty, but at design-time it is fairly easy to work around by changing the width in the DFM file directly. If you need to change the width at run-time it is easier to work with absolute column widths and do the calculations yourself, at least it is better for your mental health.

If you have forms that are not autocreated the first thing you should do is to delete the form variable (form2, form3 in your example) the IDE creates in the form unit since these variables will never be initialized unless you do it in code. Such forms, when only used modally, should be created inside the method showing them modally, and destroyed after their ShowModal method has returned and any user-entered data has been retrieved from the form. In such a scenario you use a variable local to the method showing the form to hold the form instance. Your problem is basically to select the correct form class to create the form identified by the string passed to your ShowForm method. If you can live with needing to add the units containing the form classes in question to the Uses clause of the TForm1-Unit (use the one in the implementation section) you can do something like this: procedure TForm1.ShowForm (MyText : String); var MyFormClass : TFormClass; MyForm: TForm; begin if MyText ='A' then MyFormClass := TForm2 else if MyText ='B' then MyFormClass := TForm3 else MyFormClass := nil; if Assigned(MyFormClass) then begin MyForm := MyFormClass.Create(Self); try MyForm.ShowModal; finally MyForm.Free; end; end else ShowMessage('Unknown form class requested: '+MyText); end; If you really need to show the created form modeless you need a different approach. The safest way in my opinion is to simply search for the form in the Screen.Forms collection, using the form class as the search parameter. function FindOrCreateFormByClass( aFormClass: TFormClass ): TForm; var i: Integer; begin for i:= 0 to Screen.formCount - 1 do begin Result := Screen.Forms[i]; if Result.ClassType = aFormClass then Exit; end; Result := aFormClass.Create( Application ); end; procedure TForm1.ShowForm (MyText : String); var MyFormClass : TFormClass; MyForm: TForm; begin if MyText ='A' then MyFormClass := TForm2 else if MyText ='B' then MyFormClass := TForm3 else MyFormClass := nil; if Assigned(MyFormClass) then begin MyForm := FindOrCreateFormByClass(MyFormClass); MyForm.Show; end else ShowMessage('Unknown form class requested: '+MyText); end; This works if you only ever need one instance of a form class. If you need access to the created form later you do not use the IDE-created form variable (if you did not delete it) but search through the screen.forms collection again. There are ways to eliminate the need to add the form units to the TForm1 unit uses clause but they again require a different approach. You create a "form factory" singleton object in this case (google for "factory pattern") in a separate unit. The form classes would get registered with this factory together with the string identifying the class; in the form unit's Initialization section. The TForm1 unit would the only need to add this factory unit to its uses clause, and the factory would have a public method that corresponds to your current ShowForm method.

Build events allow you to execute shell commands, like "copy" or "rename", using macros that get replaced with project related pathes etc.. Since the files are used by the finished program I would use the post build event for that. The deployment stuff is for non-Windows targets only if I understood that correctly.

The update has problems with uninstalling some GetIt packages, e. g. Parnassus Bookmarks and Navigator. It is recommended to manually uninstall these first before you run the update. I dimly remember a blog post about this issue but cannot find it at the moment. Anyway: the GetIt uninstall opens a command window that then fails to close. Just close it yourself, you may actually be able to type "exit" at its prompt for that, otherwise shoot it down via task manager. The process will then continue normally.

Have you tried to build the program as a 64 bit executable? You also need the 64 bit version of MySQL of course.

As far as I know forms (all TCustomForm descendants in fact, including TDatamodule) are not meant to be added to design-time packages. If you want to make them reusable from other projects add them to the object repository instead, this way they are accessible from the File -> New -> Others dialog.

Pascal Analyzer may be helpful in this context. It is not free but if I remember correctly you can evaluate it for a period until paying for it. Have not used it myself, though.

If you do multiple passes over the file you can end up replacing bytes in a part you replaced in a previous pass, which is usually not what you want.

This approach only works if you have one single search/replace pair.

OK; i'm done with the example code. Find a small test project attached as a zip file. It contains a unit named PB.ByteSearchAndReplaceU that implements a class TByteSearchAndReplace that encapsulates all the code for this task. It compiles and runs but I have not checked that it does do the actual replacements properly, due to the lack of test data. I leave that to you, good luck. ByteS&R.zip

That is the source of your problem because converting an AnsiChar to UnicodeChar ( = Char) is not a simple byte copy, it will convert characters not in the 7 bit ASCII set to Unicode codepoints that may have different ordinal values. This depends on the active ANSI codepage of the system as well. The only sensible solution is to treat bytes as bytes and not as characters, use TBytes or other suitable containers to store sequences of bytes instead of strings (ANSI or Unicode). Writing a Pos equivalent for TBytes is easy and there are likely dozens of implementations around, you just have to find one .

You should have given us this info in your first post since it is very relevant to the way this needs to be approached. If the whole file does not fit into available process memory you have to process it in chunks, and this opens a whole new can of worms (only a chicken would be happy about that ). You have to deal with source byte sequences exceeding the end of a chunk, for example. And do you really want to do the replacement directly on the original file, potentially risking to corrupt it if something goes wrong? Anyway, I don't have time today to whip up any coding example, so be patient. P.S. : No PM unless explicitely requested! This forum is also intended as an information source for future problems from other people.

Mine shows 28.0.46481.1287.

How large is the file you are trying to load? Did you build for a 32 or 64 bit platform? Try the latter.

D11 actually accepts initialized TBytes arrays in typed constants, so yo can do this: procedure ReplaceBytesInFile(aStream: TMemoryStream; const aSearchBytes, aReplaceBytes: TBytes); var LNumBytes: Integer; LPos, LEnd: PByte; begin LNumBytes := Length(aSearchBytes); Assert(LNumBytes = Length(aReplaceBytes), 'Arrays have to be of the same length!'); if LNumBytes = 0 then Exit; LPos := aStream.Memory; LEnd := LPos; Inc(LEnd, aStream.Size - LNumBytes ); while LPos < LEnd do begin if LPos^ = aSearchBytes[0] then begin if CompareMem(LPos, @aSearchBytes[0], LNumBytes) then begin CopyMemory(LPos, @aReplaceBytes[0], LNumBytes); // or // Move( aReplaceBytes[0], LPos^, LNumBytes ); Inc(LPos, LNumBytes); end else Inc(LPos); end else Inc(LPos); end; {while} end; type TDataRec = record SearchFor, ReplaceBy: TBytes end; const Data: array [0..1] of TDataRec = ( ( SearchFor: [$74, $00, $6f, $00, $7, $00, $73]; ReplaceBy: [$68, $00, $6f, $00, $7, $00, $73]), ( SearchFor: [$76, $00, $61, $00, $6F, $00, $70, $00, $5F, $00, $00]; ReplaceBy: [$00, $00, $61, $00, $6F, $00, $70, $00, $5F, $00, $00]) // add more data as needed, adjust array upper bound accordingly ); procedure TForm2.Test; var I: Integer; theFile: string; LBuffer: TMemoryStream; begin theFile := 'pathname here'; LBuffer := TMemoryStream.Create(); try LBuffer.LoadFromFile(theFile); for I := Low(Data) to High(Data) do ReplaceBytesInFile(LBuffer, Data[I].SearchFor, Data[I].ReplaceBy); LBuffer.SaveToFile(theFile); finally LBuffer.Free; end; end; Untested!

Please use your brain, its not just there to keep your head from imploding, you know . The code works for every byte sequence as long as both arrays are of the same length, so the total size of the data does not change.

If the background is indeed a single color you can treat that as transparent while drawing, using the TransparentBlt API function. You may have to convert the JPG to a TBitmap first, though. TBitmap has TransparentColor and Transparent properties, and a TImage with a TBitmap loaded also has a Transparent property that makes use of the TBitmap properties when rendering the image. If the background is not a single color you may have to preprocess the Tbitmap to turn pixels with colors "close enough" to clWhite to clWhite first.

That cannot be unless you are doing something seriously wrong in you UI updating or your timer intervals are very short, so the UI has no time to repaint properly. We cannot diagnose this without seeing some code...

The description sounds as if the UI thread does not process the timer messages in the expected fashion unless other messages are also in the message queue, in this case WM_MOUSEMOVE messages. This is not the normal behaviour of a Windows application. Add some logging to the timer events to check whether the events are triggered at the expected interval (OutputDebugStr should do if you run from the IDE).