I was wanting to create a small tool in Delphi which can update the Delphi version information in another exe file. I know several existing utilities are out there for this but I need full programmatic control and would prefer no shelling out to the command line, etc.
After a web search I couldn't find any Delphi source code examples of modifying version information in an exe, could anyone provide some code or direction?
I can't give a complete answer, but I can get you started. There is an article at DelphiDabbler.com that fills in how to get to the version information out of a file. GetFileVersionInfo is the Windows API to do that. To set it, I believe UpdateResource is the Windows API function you'll need to use. There is another article at CodeProject that covers this, using C, but it should give you a solid idea of what needs to be done.
Good luck!
Edit: I found some code on the Delphi newsgroups that might give you some more help:
// Credit to Michael Winter for this code!
Sz := GetLen;
GetMem(Data, Sz);
try
GetData(Data, Sz);
HFile := BeginUpdateResource(PChar(FileName), false);
if HFile = 0 then
RaiseLastWin32Error;
DoDiscard := true;
try
if not UpdateResource(HFile, RT_VERSION, PChar(1), 0, Data, Sz) then
RaiseLastWin32Error;
DoDiscard := false;
finally
if not EndUpdateResource(HFile, DoDiscard) then
RaiseLastWin32Error;
end;
finally
FreeMem(Data);
end;
It's just a snippet, and will require some work on your part, but that's the lion's share of the work!
There's also Colin Wilson's XN Resource Editor with source code which might help.
Related
I have the following issue.
I'm using Glut openGL for drawing certain elements in my application written in Delphi. The library file I'm using is called glut32.dll (placed where the EXE file is standing)
Now I decided to compile my app in 64-bit as other libraries it is using are going to be updated only for 64-bit. All fine, but the one thing that stops me is the glut32.dll (it is 32-bit). As the Glut project is not supported for many years already I found the freeglut alternative which claim to be replacement for the original Glut: https://freeglut.sourceforge.net/, and downloaded the freeglut.dll from here: www.transmissionzero.co.uk/software/freeglut-devel/ for MSVC.
As I looked at the .h header files it seems more or less the same as my code translation is in the *.pas files.
So I tried to just load the freeglut.dll instead of glut32.dll (dll is set to the correct dll name in the function below)
procedure LoadGlut(const dll: String);
begin
FreeGlut;
hDLL := LoadLibrary(PChar(dll));
if hDLL = 0 then raise Exception.Create('Could not load Glut from ' + dll);
#glutInit := GetProcAddress(hDLL, 'glutInit');
#glutInitDisplayMode := GetProcAddress(hDLL, 'glutInitDisplayMode');
#glutCreateWindow := GetProcAddress(hDLL, 'glutCreateWindow');
#glutCreateSubWindow := GetProcAddress(hDLL, 'glutCreateSubWindow');
#glutDestroyWindow := GetProcAddress(hDLL, 'glutDestroyWindow');
#glutPostRedisplay := GetProcAddress(hDLL, 'glutPostRedisplay');
...
It is loading with no errors and so on, also the procedures in it, but when the application start and reach a point to use one of these functions it just stop the debugger with no error message (like pressing Ctrl+F2).
procedure DrawArrow(P1, P2: TRPoint; Color: TRGBAColor);
var
R : Real;
begin
DrawLine(P1, P2, Color);
glColor4fv(#Color[0]);
glPushMatrix;
SetZAxis(P2, P1);
R := VectorModulus(VectorDifference(P1,P2));
glTranslated(0, 0, R);
SetSymbolScale;
glTranslated(0, 0, -ARROW_L);
glutSolidCone(ARROW_W/2, ARROW_L, SOLID_SLICES, SOLID_STACKS);
glPopMatrix;
glPopMatrix;
end;
The debugger shut itself at glutSolidCone(ARROW_W/2, ARROW_L, SOLID_SLICES, SOLID_STACKS); This function is defined in freeglut as well.
EDIT: If I call other simple function like glutInitDisplayMode it doesn't stop, so it seems that the library is correctly loaded. But it still keeps shutting down at glutSolidCone or other drawing functions.
I don't have much experience of using these header files and dll that comes with it, but my Delphi code should be a good translation in this case? Or not? I don't know how to debug this.
What is the way to adapt my code in order to fit freeglut in it. It should be something small I think as most of the things should be the same.
Thank you for the help
It seems that just replacing glut32.dll with freeglut.dll won't do the job properly as I guess functions inside differs a bit (or simply renaming freeglut.dll --> glut32.dll also fails). However I found a workaround published by NVIDIA: NVIDIA Cg Toolkit
It is not supported since 2013, but when installed it brings the dll version of glut32 both for 32-bit and 64-bit development. Quickly try it and it seems to work and cover what I have as definition in Glut.pas.
So if you need 64-bit version and replacement of glut32.dll it can be downloaded from there.
Meanwhile if somebody convert the freeglut headers (.h) to Delphi code it would be great as at the end the Freeglut projecy is still maintained, up-to-date and add some more useful functions in addition to the original Glut. This conversion is still beyond my knowledge.
I am trying to accept file uploads in a Delphi 7 Webbroker CGI.
I'm using Shiv Kumar's TMsMultipartParser, but I have a problem with Chrome. I can't access the parsed data (surprisingly, Explorer works fine).
This is my code:
with TMsMultipartFormParser.Create do
begin
Parse(Request);
lsExternalID:=ContentFields.Values['external_id'];
if (lsExternalID='') then
raise Exception.Create('No external ID');
for i := 0 to Files.Count -1 do
begin
lsFileName:=files[i].FileName;
//Rename file using external ID (not included for simplicity)
Files[i].SaveToFile(lsFilename);
end;
Response.Content := 'OK';
free;
end;
As suggested here, I tried to use http://www.mrsoft.org/Delphi/MultipartParser.pas but I can't compile it. It uses a unit called UniversalUtils that I can't find anywhere.
I know this is a very obsolete technology. Almost all references to it have already disappeared from the web (believe me, I have searched). Buy any help would be deeply appreciated.
Thanks.
I finally solved my problem, thanks to #mrabat.
This project started in Delphi 5. It was later upgraded to Delphi 7 (it can't be upgraded further, because many parts can't support Unicode strings, we use ANSI).
We were using Shiv's TMsMultipartParser because Delphi 5 didn't have any parser included.
Delphi 7 has TMultipartContentParser in unit ReqMulti.pas, and it works perfectly.
For anyone that need an example, I'll post my working code:
with TMultipartContentParser.Create(Request) do
begin
lsExternalID:=ContentFields.Values['external_id'];
if (lsExternalID='') then
raise Exception.Create('No external ID');
for i := 0 to Request.Files.Count -1 do
begin
lsFileName:=Request.Files[i].FileName;
//Rename file using external ID (not included for simplicity)
TMemoryStream(Request.Files[i].Stream).SaveToFile(lsFilename);
end;
Response.Content := 'OK';
Free;
end;
I wrote something similar once here:
https://github.com/stijnsanders/xxm/blob/master/Delphi/common/xxmParams.pas#L159
but that may be tightly coupled with SplitHeaderValue that parses the header lines, and TStreamNozzle that throttles incoming data. (and TXxmReqPar... objects, and IXxmContext...)
(Of course you're warmly welcomed to accept file uploads with xxm...)
I need to copy a form (Delphi 2007) to the clipboard as an image to paste what the user can see into a word document. The clipboard part is not really a problem. The questions is how to get a bitmap for the form.
Searching has turned up multiple options.
Call GetFormImage
Use the PrintWindow API function that is part of the GDI+
Send a WM_PRINT message
Copy the Canvas for the current form using Canvas.CopyRect
I also found a component called TExcellentFormPrinter that has a solution that claims to works better than any of these options, but I don't know what method it is using.
All of these options seem to have different problems. Most of the information I am finding seems to be outdated. I can't seem any good source that compares the different options with enough detail for me to make a choice. Any advice on which option to go with.
I have tried these on my form and they all seem to work OK, I just trying to avoid problems down the road. Any advice on what solution to go with?
Update: What Potential Problems with GetFormImage?
Andreas asked what the problem is with GetFormImage. Hopefully nothing anymore, that is part of what I am trying to get an answer to. What has me concerned is so many of my search results seem to be suggesting creative alternatives to using GetFormImage. I was hoping the answers would clear up the waters a little bit.
I would be really happy with an answer that got a lot of up votes that said - GetFormImage used to have some problems but there is no reason not to use it now. :-)
As to the actual problem with GetFormImage. One issue for some users was only the visible part of the form would appear in the image (i.e. you can't capture a hidden or overlapped window). That is not really an issue for me as my entire form is visible.
1) The bigger issues deal with specific support required from the controls on your form. The Delphi 4 Fixes and Known issues page list has this entry (note it is listed as "Deferred to Next"). I could not find a QC entry that showed this resolved:
Area: vcl\core vcl classes
Reference Number: 1088 (Published: 12/16/98)
Status: Deferred to Next
Rel Date Reported: 8/6/98 Severity:
Commonly Encountered Type: Basic
Functionality Failure Problem:
The problem is with GetFormImage most nest windows controls like comboboxes, etc. are drawn blank.
2) I am also using the DevExpress controls. At one time their controls (fixed at the end of 2006) did not support the PaintTo messages that GetFormImage was using. This is fixed in the DevExpress release I am using, but it raises other issues with me, what is the chance that other control I am using may not work correctly?
3) Here is a more recent (2010) post on the Embarcadero Groups. The user was having trouble using GetFormImage where part of the graph they were showing on screen did not appear in the final image. They also needed the form caption included (which I do not) and they took the Canvas.CopyRect approach outlined in this post.
4) Here is the quote from the TExcellentImagePrinter page. I would have no problem buying their product if needed. There component looks like it was last updated in 2002 (There is a Delphi 2007 trial version though). I can't tell if I really need to go that direction or not.
You can try using GetFormImage or
Form.Print. Try dropping a ComboBox
down on a form, then call GetFormImage
or Form.Print. If you get a
printout, do you see the text in the
ComboBox? No? Neither does anyone
else! This is only a small example of
the problems you will encounter when
printing VCL forms.
You can also try using Borland's
TI-3155 "A better way to print a
form". I wrote the TI when I worked at
Borland as a stop gap measure. While
it will print the combobox text, it
will fail on many printers, it can't
print the entire form if your user has
resized the form, and it can't print
forms that are hidden from view or is
located partially off the screen. The
code basically produces a screenshot,
and to print an image reliably, you
would probably want to take a look at
our TExcellentImagePrinter product!
Why? Simply put, it can require a
couple of thousand lines of low level
graphics code to get bitmaps to print
well under Windows.
I do not know what the problem is with GetFormImage, but an option that you have not tried (at least not explicitly) is
procedure TForm1.FormClick(Sender: TObject);
var
bm: TBitmap;
begin
bm := TBitmap.Create;
try
bm.SetSize(ClientWidth, ClientHeight);
BitBlt(bm.Canvas.Handle, 0, 0, ClientWidth, ClientHeight, Canvas.Handle, 0, 0, SRCCOPY);
Clipboard.Assign(bm);
finally
bm.Free;
end;
end;
In almost all cases I would expect this to produce the same result as
bm := GetFormImage;
try
Clipboard.Assign(bm);
finally
bm.Free;
end;
though. (Also, the Canvas.CopyRect procedure employes StretchBlt which I would expect to produce the same result as BitBlt when no stretching is applied.)
Method 2
You can always use Print Screen:
procedure TForm1.FormClick(Sender: TObject);
begin
keybd_event(VK_SNAPSHOT, 1, 0, 0);
end;
This will also capture the border and the title bar. If you only wish to obtain the client area, you can crop the image:
procedure TForm1.FormClick(Sender: TObject);
var
bm, bm2: TBitmap;
DX, DY: integer;
begin
Clipboard.Clear;
keybd_event(VK_SNAPSHOT, 1, 0, 0);
repeat
Application.ProcessMessages;
until Clipboard.HasFormat(CF_BITMAP);
bm := TBitmap.Create;
try
bm.Assign(Clipboard);
bm2 := TBitmap.Create;
try
bm2.SetSize(ClientWidth, ClientHeight);
DX := (Width - ClientWidth) div 2;
DY := GetSystemMetrics(SM_CYCAPTION) + GetSystemMetrics(SM_CYSIZEFRAME );
BitBlt(bm2.Canvas.Handle, 0, 0, ClientWidth, ClientHeight, bm.Canvas.Handle, DX, DY, SRCCOPY);
Clipboard.Assign(bm2);
finally
bm2.Free;
end;
finally
bm.Free;
end;
end;
We have a client server software that needs to be updated. I need to check if the file is currently being accessed. Is this possible if so how Delphi code if possible. The only place I can see if the file is open is under the shared folders open files. I have tried this code but just shows that the file is not opened.
function TfrmMain.FileInUse(FileName: string): Boolean;
var H_File : HFILE;
begin
Result := False;
if not FileExists(FileName) then
begin
showmessage ('Doesnt Exist');
exit;
end;
H_File := CreateFile(PChar(FileName), GENERIC_READ or GENERIC_WRITE, 0,
nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
Result := (H_File = INVALID_HANDLE_VALUE);
showmessage('Opened');
if not Result then
CloseHandle(H_File);
end;
There is a great deal of information you can access over the WBEM sub-system provided by Windows. I believe there are good WBEM components out there, but you could also import the "Microsoft WMI Scripting" COM Type Library (though this takes a little work to figure out how it works).
If you query for Win32_ServerConnection objects, you get a list of items currently in use, much like you can view using the 'Computer Management' tool from the Administrative Tools.
Not necessarily an answer, but I am currently doing something similar - because the main executable might be updated during working hours though I have created a intermediary application that checks to see if a locally cached copy of the file is up to date, I then run this locally cached copy.
I found this similar item, someone proposes to use the NetFileEnum function
I have installed Delphi Prism and XNA Game Studio 3.0. I have managed to translate to Delphi Prism XNA Tutorial 1 "Displaying a 3D Model on the Screen" (http://msdn.microsoft.com/en-us/library/bb197293.aspx).
Project compiles fine, but I cannot load a model. It looks like there is a new "contentproj" type in XNA that is not in Delphi Prism...
Any idea how to get it to work?
You could just manually build the content project using msbuild. It might not have the same integration where you can just add content and change settings in solution explorer ... but it'll do the trick :-)
here is more info about this: http://blogs.msdn.com/shawnhar/archive/2006/11/07/build-it-ahead-of-time.aspx
I have finally managed to get it to work via 1) building "*.contentproj" with MSBuild from command line, 2) coping the resulting "Content" directory as a subdirectory where my Delphi Prism executable is outputted.
It would be nice to have Delphi Prism recognizing *.contentproj automatically and build it automatically.
I haven't done any XNA stuff yet, but here is my best guess :-)
So, the Content Project type is a sub-project for a standard XNA project that just compiles the game content (textures, sound etc) as a nested compile process, correct?
So I would assume that there must be some reference to the sub-project in either the project file or the solution file, perhaps the best way would be to create a simple XMA proj in C# or VB and look at the generated meta-files (csproj, contentproj etc)
Edit:
Oh, I'm suggesting here that you manually create the contentproj file and insert the reference, once you know what they look like, I assume that VS will then allow you to add, delete your content etc
That then just leaves the question of how is the XNA content pipeline compile process is fired, if it doesn't "just happen" that might be a question for marc hoffman et al
Hope this helps a little, its just a guess.
Good to see you in StackOverFlow by the way.
Rgds Tim Jarvis.
According to my knowledge, Prism is only announced and not released. Hence the trial is not a final product. As a RO customer I expect an email come release, but not before except for the announcement of it. Frankly, I don't know that XNA support is finalized or even working yet. You might be premature in trying this, given that the official release of Prism is still almost a month away at the soonest.
I don't know what to tell you to do to fix your problems with XNA, but it would be wise to wait for Prism itself. Until Prism is released I would consider XNA support "pending".
System.reflection can be used to gain access to inner workings of XNA to create xnb files
method Game1.LoadContent;
var
importer : TextureImporter;
texContent : Texture2DContent;
cc : ContentCompiler;
fullPath : String;
fs : FileStream;
args : array[1..7] of System.Object;
begin
spriteBatch := new SpriteBatch(GraphicsDevice);
importer := new TextureImporter;
texContent := importer.Import(’asset.png’, nil) as Texture2DContent;
var compilerType := typeOf(ContentCompiler);
cc := compilerType.GetConstructors(BindingFlags.NonPublic or BindingFlags.Instance)[0].Invoke(nil) as ContentCompiler;
var compileMethod := compilerType.GetMethod("Compile", BindingFlags.NonPublic or BindingFlags.Instance);
fullPath := ‘assestName.xnb’;
fs := File.Create(fullPath);
args[1] := fs;
args[2] := texContent;
args[3] := TargetPlatform.Windows;
args[4] := GraphicsProfile.Reach;
args[5] := true;
args[6] := fullPath;
args[7] := fullPath;
compileMethod.Invoke
(
cc,
args
);
//SpriteTexture := Content.Load(’assetName’);
end;