PeterBelow

You can select and copy the path from the edit field and paste it into Notepad to check it for invalid characters or nonexistent pathes, perhaps that reveals a problem.

You can only put code in the OnStart event handler that executes fast and does not block the thread, otherwise it will prevent the service from starting because the service manager runs into a timeout waiting for the event handler to return. Better just create a secondary thread in OnStart and do all other work in/from its Execute method.

Launch the dialog before you do anything with the Printer object (i.e. construct your print job). The VCL TPrintDialog and TPrinterSetupDialog components modify the Printer properties according to the user's selection in these dialogs.

I found some really ancient code for this in my old snippets file, perhaps you can get it to work. It loads a JPEG from file but you can load it from a TBlobstream attached to your field as well. Printing a JPEG image: uses jpeg, printers; // This procedure has been adapted from the one found near the end of // the Delphi 1 MANUALS.TXT file. procedure PrintBitmap(Bitmap: TBitmap; printrect: TRect); var Info: PBitmapInfo; InfoSize: Cardinal; Image: Pointer; ImageSize: Cardinal; begin with Bitmap do begin GetDIBSizes(Handle, InfoSize, ImageSize); Info := AllocMem(InfoSize); try Image := AllocMem(ImageSize); try GetDIB(Handle, Palette, Info^, Image^); with Info^.bmiHeader, printrect do StretchDIBits(Printer.Canvas.Handle, Left, Top, Right-Left, Bottom-Top, 0, 0, biWidth, biHeight, Image, Info^, DIB_RGB_COLORS, SRCCOPY); finally FreeMem(Image, ImageSize); end; finally FreeMem(Info, InfoSize); end; end; end; procedure TForm1.Button1Click(Sender: TObject); var bmp: TBitmap; jpegimage: TJPegImage; outputrect: TRect; i: Integer; begin jpegimage:= TJPegImage.Create; try jpegimage.Loadfromfile('d:\daten\pix\fraktal_1.jpg'); bmp := tbitmap.Create; try bmp.assign( jpegimage ); i:= 1; While ((i+1)*bmp.Width < printer.pagewidth) and ((i+1)*bmp.Height < printer.pageheight) Do Inc(i); outputrect := Rect( 0, 0, i*bmp.width, i*bmp.height ); try printer.Orientation := poLandscape; printer.begindoc; PrintBitmap( bmp, outputrect ); except printer.abort; raise; end; printer.enddoc; finally bmp.Free; end; finally jpegimage.free end; end;

Result is only available in a Function, while your current code is in a Procedure. Have you ever taken the time to read the Delphi Language Guide? It is part of the IDE main help file. It's a bit disturbing to see that such a basic thing has tripped you up...

Is Application.MainformOnTaskbar set to true or false in the DPR file? Or are you using an ancient Delphi version that does not support this property? Do any of the misbehaving forms override the CreateParams method?

You usually get that on lines that have been removed by the smart linker since it has concluded that this code is never executed. If you are sure that the code can be reached your source file may contain invalid line breaks (just CR or just LF instead of the CR LF pair). The IDE editor still breaks the line on such characters but it throws off the calculation of source code locations from the compiled binary. You can get such bad line breaks if you paste code copied from a web page or get source from an improperly configured version control system. As a test, place the editor's caret at the end of the line before the one with the missing dot and press the DEL key until the break is removed, then hit the RETURN key to insert a proper line break. Rebuild the project and see if the dot is now there.

You should use a TRadiogroup instead of individual TRadiobuttons. You can then save and restore the ItemIndex of the group-

Sorry, I cannot help you with that; my knowledge of TWebBrowser is pretty basic.

How do you display the result? You can control the number of decimals displayed when converting a floating-point value from its internal binary (not decimal!) representation, but the exact syntax depends on the function you use (Write, WriteLn, Format, FormatFloat, FloatToStr, FloatToStrF etc. The run-time library has accumulated quite a number of such conversion functions over time. Oh, and the result of your multiplication is actually not exactly 99,49995 since the computer stores numbers as binary and not as decimal, and since it only has a limited number of bits available many decimal numbers cannot be stored without a small loss of precision. These errors accumulate over calculation steps...

Well, the image source file is specified using a relative path. But what is it relative to? If you open a HTML file in a web browser the path is relative to the folder the HTML file resides in, if you serve the HTML from a web server it is relative to the folder defined as root for the web page. If you load the HTML directly into a TWebbrowser it may be relative to the current directory as seen by the running program. As a test set the current directory in the program to the folder that contains the img subfolder, using the System.IOUtils.TDirectory.SetCurrentDirectory method, before loading the HTML string. Oh, and forget the old file functions, TFile from System.IOUtils has ReadAllText method that does the job in one line...

To change the folder for the project source file open the project in the IDE and use the "Save project as..." menu entry of the File menu to save the DPR and DPROJ files in the new location you want. Then open each file (form, frame, datamodule) in the IDE and use the "Save as..." menu to save it to the new folder. Finally use "Project -> view source" to open the DPR file in the editor and check the entries in the Uses clause and any $R statements for pathes that still refer to the old folder. This is certainly laborious but the safest way to make sure the entries in the DPROJ and DPR file are changed properly to the new location. You will retain the files in the old location this way and can zip them up or delete them at leisure. If the project is large (many files to move) it may be easier to just move the files to the new folder (with the IDE not running!) using Windows explorer, delete the DPROJ and any files with "local" in the extension, open the DPR file in a text editor (not the IDE), correct any pathes that need it there, and then open the project DPR file from the new location in the IDE. That will create a new DPROJ file, you then just need to check the project options to modify the output folder to your requirements.

You are not understanding the concept of identifier scope correctly. Gamespeed is a property of the class TGameWindow, which is defined in unit GameWindow. To access it in your TGame class this class has to derive from TGameWindow (in which case is can access all members of TGameWindow that are not declared private) or you need an instance of TGameWindow accessible from TGame, in which case you have to change the code to qualify Gamespeed with that instances name, e.g. FWindow.Gamespeed, if FWindow is the variable/field containing the TGameWindow instance. If you want all instances of the TGameWindow class to share the same Gamespeed value you can change the property into a class property and the corresponding field and accessor methods to class field and class methods. In this case you can use the syntax TGameWindow.Gamespeed in TGame.Start to access the property.

Are you working on an older project written by someone else? Which database framework does it use, FireDAC, IBObjects, ADO (dbGo), BDE, some 3rd-party framework? In a properly designed DB app there should be only one place that uses the actual database name: the object handling the database connection/session . All other objects accessing the database should use this connection instance. A possible exception are apps that need to work with the same database from more than one thread, since DB sessions are usually bound to the thread that creates them.

If the Cobol programm passes a HBITMAP to the DLL procedure the following may work: In the DLL procedure, create a TBItmap object assign the passed HBITMAP to that objects Handle property adjust with and height of the bitmap object to the signature bitmap's dimensions, if necessary draw the signature bitmap on the bitmap object's canvas (using Assign instead may recreate the bitmap Handle) set the bitmap Handle to 0 to disconnect the passed HBITMAP from the TBitmap object destroy the temporary TBitmap object. If the Cobol program can get you a HDC from its bitmap you can pass that to the DLL instead of a HBITMAP and use BitBlt directly to copy the signature to it. That requires the Cobol program to properly size the bitmap first, though.

What you see is due to rounding errors when scaling individual character widths, these accumulate over the text width. If you want true WYSIWYG display you have to basically place each character individually at positions calculated from the font information. The API offers a large group of functions for this purpose, see Font and Text Functions

Design-time packes are only 32 bit, they are only used by the IDE and this is 32 bit programm. Run-time packages (that is what youre compiled programs use) can be 32 or 64 bit. Put the component class into a run-time package and add that to the requires clause of the design-time package. The only thing that package does is registering the component, i. e. it contains the Register procedure the IDE looks for to add the component to the palette. See https://docwiki.embarcadero.com/RADStudio/Alexandria/en/64-bit_Windows_Application_Development#Making_Your_Components_Available_at_Design_Time_and_Run_Time in the online help. It also tells you how you can specify which platforms your component is compatible with (ComponentPlatformsAttribute) if the default is not to yor taste.

In theory you can create a VCL control (not forms or datamodules since they add themselves to the global Screen object's collection) in a background thread but you cannot do anything with it that causes its window handle to be created, since that would bind it to the background thread. Things like TBitmap or TGraphicControl descendents (the latter only as long as they have no Parent assigned) should work, and I have worked with TBitmap in background threads successfully. To show them you have to pass them to the main thread, though.

The VCL is not thread-safe and has been documented to not be thread-safe since Delphi 1. If you need to create Windows controls in a secondary thread you have to do it on the naked API level, and the thread probably needs a message loop (API style, not ProcessMessages) as well for the control to work properly.

You are assuming Sizeof(Char) = 1, which is no longer true since Delphi 2007. Use ballpointer:=GetMemory(3000000*Sizeof(char)); Incrementing a pointer to Char (PChar) will correctly take the size of Char into account, so your statement ballpointer:=ballpointer+1; will increment the address held in ballpointer by 2. Since GetMemory takes the size in bytes your code allocates only half the memory needed for 3,000,000 UTF16 characters, so the loop runs over the end of the buffer when it is halfway through.

They are of type String already. The limitation seems to be in the parser which cannot deal with lines longer than 255 characters in the source. But there is an easy workaround, which your third-party tool should use for long string literals: split it into several shorter literals concatenated by '+' plus linebreaks. Much easier to read for you as well if you need to manually correct stuff later.

The compiler accepts this without problems: const CTest = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'+ '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' ;

Isn't the Last Author set when the file is saved? That would simply undo your change...

There is a case, though: if the code inside the try block calls something in a DLL and that DLL function does not trap any exceptions raised inside the DLL code these would bubble up the exception handler stack into your try except block, be trapped there but not recognized as deriving from the Exception class. This would even be the case if the DLL is written in Delphi, unless DLL and EXE are build with the same Delphi version and with run-time packages enabled for both projects.

Which OS/CPU are we talking about here? What you show has not been a problem since 16-bit (DOS, Win 2.x, 3.x) programs have gone the way of the dinosaurs. 32 and 64 bit CPUs use a different memory architecture. 32 bit CPUs (Intel) do in fact still have segment registers but their content is constant during normal program runs, and the offset (address) registers are 32 bit wide, so a memory block can be up to 4GB large in theory. Due to OS requirement (Windows) 32 bit application programs can only use 2GByte of this theoretical address space though (3GByte with a special executable flag).