I just found that lockbox 3.6.0 should support Android. However when i look in my palette i see that the codec only supports win32 and win64.
How can i make it work for my android apps also?
Im using Delphi XE7 and have already followed the installation instructions supplied in the package. For a windows app it works just fine.
You have two options:
(1) Run-time
You can always create the components at run-time. There is an example on the website on how to do it, and I copy a fragment of this example below. Just replace the ShowMessage() functions with whatever is appropriate ...
procedure EncryptAStream( Plaintext, Ciphertext: TStream);
var
Codec1: TCodec;
CryptographicLibrary1: TCryptographicLibrary;
begin
ShowMessage( 'Demonstration of How to Encrypt a Stream with TurboPower LockBox 3.');
Codec1 := TCodec.Create( nil);
CryptographicLibrary1 := TCryptographicLibrary.Create( nil);
Codec1.CryptoLibrary := CryptographicLibrary1;
Codec1.StreamCipherId := uTPLb_Constants.BlockCipher_ProgId;
Codec1.BlockCipherId := 'native.AES-256';
Codec1.ChainModeId := uTPLb_Constants.CBC_ProgId;
Codec1.Password := 'my utf-16le password';
// Codec1.Reset; Reset if you are continuing from a previous encryption operation.
Codec1.EncryptStream( Plaintext, Ciphertext);
// Codec1.Burn; Burn if you need to purge memory of sensitive data.
Ciphertext.Position := 0;
ShowMessageFmt(
'The ciphertext for AES-256 with CBC chaining'#13#10 +
' of plaintext ''banana'' (UTF-8 encoding),'#13#10 +
' and password ''my utf-16le password'' (UTF-16LE encoding),'#13#10 +
' prepended by 64 bit nonce, (being the IV),'#13#10 +
' and rendered for display in base64 is ...'#13#10 +
'%s', [Stream_to_Base64( Ciphertext)]);
Codec1.Free;
CryptographicLibrary1.Free;
end;
(2) Design-time
A little bit of tweaking is required to get the components onto the palette for Android. This will be done for you in the next version of TPLockbox 3 to be released, but for now, here is the procedure ...
Remove vcl, vclimg and dbrtl from the TPLB3 run-time requirements.
For the run-time package, add the Android target platform, and make it the active one. But of course, don't add this platform to the design-time package.
The binary product for the run-time should be named libTP_LockBox3_XE7.so, where XE7 is a place-marker for your compiler version.
Preface the declarations for the two components (TCodec and TCryptographicLibrary) with
[ComponentPlatformsAttribute( pidWin32 or pidWin64 or pidOSX32 or pidiOSSimulator or pidiOSDevice or pidAndroid)]
TCodec = class( TTPLb_BaseNonVisualComponent, ICryptographicLibraryWatcher,
{ etc. }
This is the key to the whole thing. The ComponentPlatformsAttribute attribute declares what platforms should the component be displayed for, on the palette. If not declared, I believe that the default is pidWin32 or pidWin64, but I cannot point to any official documentation to support this.
Recompile the run-time package. Remember that if your are compiling with MS-BUILD, on certain compiler versions, you need to save-all before you can successfully compile.
Go to the IDE Tools | Options and open the Library Path for the Android platform. Make sure that this path include the location of where you put the dcu files for the Android case. For example, on my installation it is ...
C:\Dev\TPLB\work-products\ephemeral\dcu\XE6\Android
You should physically check this directory. It should have a file named TPLB3.AES.dcu and another named TPLB3.AES.so for example.
Recompile and re-install the design-time package
Open your mobile project. Slap design-time components for TCodec and TCryptographicLibrary on your Android forms. Proceed as you would for a windows application.
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 use Delphi X10 and Word 2016 64-bit on Windows 10 64-bit.
I always used ComObj.
for example:
uses ComObj;
procedure TForm1.RzBitBtn1Click(Sender: TObject);
var Excel: variant; i, j: word;
begin
Excel := CreateOleObject('Excel.Application');
Excel.Workbooks.Open('file.xls');
for i := 1 to 5 do
for j := 1 to 5 do
StringGrid1.Cells[j, i] := Excel.Sheets[1].Cells[i, j].Text;
end;
But, i want to use autocompleate for Excel methods. I read what i should import type library, but i cant find type library file in my system.
This is quite easy to do, as long as the type libraries for Excel anmd Word are correctly registered.
Go to the OCX\Servers folder under your Delphi install and find Word2010.Pas. Add it to a new VCL project, and USE it in the main form's unit. Declare a form variable A: WordApplication on your main form.
With that done, you should be able to go to Form1's Form.Create, type
A.
and autocomplete should offer you the possibilities for WordApplication's methods and properties.
Now, open Word2010.Pas and find the section
// File generated on 2/20/2013 5:56:45 PM from Type Library described below.
// ************************************************************************ //
// Type Lib: c:\Program Files\Microsoft Office\Office14\msword.olb (1)
// LIBID: {00020905-0000-0000-C000-000000000046}
That tells you the name and location of the type library which was used to generate Word2010.Pas.
Now, unless you need to use some method/property that has been added to Word/Excel since the 2010 version, Word2010.Pas and Excel2010.Pas may be all you need. However, you can import the type library of a more recent version using Delphi and have it generate an import unit for it. Exactly how to do that depends on your Delphi version, but for Delphi Seattle. you simply go to Component | Import Component from the IDE main menu, then select Import type library in the pop-up and follow the wizard's prompts.
Once you've generated the import unit, obviously you simply USE it in your project instead of MSWord2010.
Btw, strictly speaking, there is no "Delphi X10", recent versions (since XE8) have been Seattle, Berlin and Tokyo.
Until recently it was simple to read all the SVN:Externals referenced in a subversion working copy by just reading some text files stored in the .svn subdirectory. With the change to a new on disk structure using mysql tables this is no longer that simple.
I want to update an internally used tool that used to read that list of externals to using the new structure. The Tool is written in Delphi 2007 so I would prefer some code written in Delphi.
There is Version Insight for RAD Studio on sourceforge which might contain some code to do the trick but I wonder if any body else has maybe already gone through the work of extracting the required parts from that project or has an alternative.
You can also do it programmatically, using the Subversion client DLLs. Here is a minimal example written in Delphi XE:
program svnext;
{$APPTYPE CONSOLE}
uses
SysUtils,
SvnClient;
procedure Main;
var
SvnClient: TSvnClient;
SvnItem: TSvnItem;
begin
// Subversion client DLL directory; here I simply use the .exe's directory
// (I copied the DLLs there manually.)
BaseDllDir := ExtractFilePath(ParamStr(0));
SvnClient := nil;
SvnItem := nil;
try
SvnClient := TSvnClient.Create;
SvnClient.Initialize;
SvnItem := TSvnItem.Create(SvnClient, nil, ParamStr(1));
Writeln(SvnItem.PropValues['svn:externals']);
finally
SvnItem.Free;
SvnClient.Free;
end;
end;
begin
try
Main;
except
on E: Exception do
begin
ExitCode := 1;
Writeln(Format('[%s] %s', [E.ClassName, E.Message]));
end;
end;
end.
You might have to tweak the code for Delphi 2007. It seems Version Insight has evolved in the meantime and lost (some of) the backward compatibility.
If you can call the svn executable, it is pretty easy to find all the externals stored in your repository :
svn propget -R svn:externals .
will return :
first/path/to/external - name_of_first_external http://first_repos/that/is/in/external
second/path/to/external - name_of_second_external http://second_repos/that/is/in/external
Like others said, call the SVN executable. You can integrate this with the Delphi Tools menu using this technique:
http://delphi.wikia.com/wiki/Adding_TortoiseSVN_to_the_Tools_menu
To add to that article, it's also VERY handy to have an "open folder here" entry that opens Windows Explorer for the folder of the file being edited. Here's the "tool properties" for that:
Title: Open Folder Here
Program: explorer.exe
Parameters: $PATH($EDNAME)
If you have this, then you've got all of TortoiseSVN at your fingertips.
I have TMS TWebCopy 2.3 on Delphi 2010.
When i try to do this:
procedure TForm1.WebCopy1Error(Sender: TObject; ErrorCode: Integer);
begin
showmessage('Error '+inttostr(ErrorCode));
end;
and
with webcopy1.items.add do
begin
url:='http://zcvhxhjcgv.com/asdfsag.zip'; //fictional url, error must appear
targetdir:=tgt.text;
end;
I have NOT get any errors! When I try to download 5-10 files WebCopy can notify 1 time, but anothers - NO.
WebCopy creates empty files with names from URL with sizes 921, 935 bytes.
The same situation for TForm1.WebCopy1ErrorInfo, TForm1.WebCopy1URLNotFound, TForm1.WebCopy1ConnectError.
I have written to support center of TMS, I do not know they reply me with any suggestion or not.
If you have the source, Delphi might be recompiling the TWebCopy.
Implicitly substituting all strings from AnsiStrings into WideStrings.
Make a backup.
And replace all string's into Ansistring in the source of TWebCopy.
Recompile and see if that helps.
or
Find the original DCU of TWebCopy and put the TWebCopy source out of harms way
and let Delphi use the original DCU, instead of the recompiled Widestringed DCU.
I'm testing a non visual ActiveX control based on a registered .ocx
which I import into Delphi using the provided wizard.
Then, I simply put the generated component on the main form of a new VCL application.
Under old Delphi versions (D5 and D2007), when i launch the application, this raise an AV
during the component initialization.
with Delphi 2009 : no problem, the application starts smoothly.
My questions are :
Are there known enhancements of ActiveX management in recent Delphi versions which
can explain this difference ?
Can I suspect a bug in the ActiveX control, or can I consider the origin of the
problem is from old Delphi versions ?
I need to use this component (if tests OK) in D2007.
Do you think that it is possible to correct the AV problem under D2007 by modifying the D2007 generated .tlb file (for example by trying to use the D2009 generated one)
PS: the ActiveX control is not named, because my question is a general question about Delphi and ActiveX, not about a specific ActiveX control.
Edit :
With D2007, the error (an Access Violation) appears during Application.CreateForm(TForm1, Form1);
and more specifically when the Olecontrol is created :
procedure TOleControl.CreateInstance;
var
ClassFactory2: IClassFactory2;
LicKeyStr: WideString;
procedure LicenseCheck(Status: HResult; const Ident: string);
begin
if Status = CLASS_E_NOTLICENSED then
raise EOleError.CreateFmt(Ident, [ClassName]);
OleCheck(Status);
end;
begin
if not (csDesigning in ComponentState) and
(FControlData^.LicenseKey <> nil) then
begin
// ON THE LINE BELOW : the call of CoGetClassObject raise an AV
OleCheck(CoGetClassObject(FControlData^.ClassID, CLSCTX_INPROC_SERVER or
CLSCTX_LOCAL_SERVER, nil, IClassFactory2, ClassFactory2));
LicKeyStr := PWideChar(FControlData^.LicenseKey);
LicenseCheck(ClassFactory2.CreateInstanceLic(nil, nil, IOleObject,
LicKeyStr, FOleObject), SInvalidLicense);
end else
LicenseCheck(CoCreateInstance(FControlData^.ClassID, nil,
CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IOleObject,
FOleObject), SNotLicensed);
end;
As far as I remember there were major enhancements to the ActiveX/TLB import in Delphi 2009 (related to Unicode support) - that might explain it.
In my personal experience Delphi 7 and Delphi 2007 repeatedly failed to import some Windows 7 type libraries (various new interfaces to work with new taskbar), but Delphi 2009 managed that without any problems at all.
As for using Delphi 2009 generated file in earlier versions - beware of Unicode issues. Plus it won't help if the defect is in RTL... Try to make a wrapper ActiveX in Delphi 2009 and use it in Delphi 2007 - that should work.
Sorry to barge in so late after the battle (5 years later as a matter of fact), but I wasted so much time on this precise issue that I thought I should share what I've seen and what I've done to solve it :
2 machines (win7 64 / win 8.1) same delphi 7 (same version same build), same activeX (MapX to name it) with identical .lic files containing the key made of 59 characters :
uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C934220-04969-6562
same import producing 2 slightly different TLB.
The one working : (on win 8.1) contains this in procedure TMap.InitControlData :
const
CLicenseKey: array[0..61] of Word = ( $0075, $0051, $006E, $005A, $0069, $0032, $0073, $0046, $0077, $0032, $0032
, $004C, $0030, $002D, $004D, $0052, $0061, $0038, $0070, $0059, $0058
, $002D, $0031, $0045, $0032, $0050, $0038, $0030, $0036, $0035, $002D
, $0035, $004E, $0035, $004D, $0033, $0034, $0035, $0039, $002D, $0033
, $0043, $0039, $0033, $0034, $0032, $0032, $0050, $0030, $002D, $004D
, $0030, $0034, $0039, $0036, $0039, $002D, $0036, $0035, $0036, $0032
, $0000);
which translates to a 61 char key
uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C93422P0-M04969-6562
The TLB that does not work (win 7 64) contains this instead:
const
CLicenseKey: array[0..2] of Word = ( $0050, $004D, $0000);
which translates to a 2 char key
PM
Replacing one const with the other and recompiling the component solved my issue. I don't really know what happened. I just know the Import/TLB produced a bad .pas file that can be corrected manually.