Jump to content

A.M. Hoornweg

Members
 View Profile  See their activity

  • Content Count

    494

  • Joined

  • Last visited

  • Days Won

    9

Posts posted by A.M. Hoornweg

  4. Posted · Edited by A.M. Hoornweg

    I suspect that it may do so.  The "const" makes no difference. Using "VAR" instead of "OUT" also fixes the issue. 

     

    I am quite alarmed by this issue because recently, whilst refactoring, I started replacing a lot of "VAR" parameters by "OUT" in order to make it more concise to a reader how the parameters are affected.  But now it appears that "OUT" is dangerous if you pass the same parameter multiple times.

  5. Posted

    Hello all,

     

    I think I've discovered an anomaly in Delphi string behavior. Consider the following code: 

    procedure TForm1.Test(const Defaultvalue: string; out Resultvalue: string);
begin
  Resultvalue:=AnsiUpperCase(Defaultvalue);
  ShowMessage(Defaultvalue+'.'+Resultvalue);
end;

procedure TForm1.Button1Click(Sender: TObject);
var s:string;
begin
   s:='default';
   Test(s,s);
end;

     

    The output produces just a dot, which makes no sense to me.

     

     

  6. Posted

    8 hours ago, David Heffernan said:

    Parsing the detailed map file is probably the easiest way to do this is a large project.

     

    If you know you have dependencies on initialization order, I'd solve the problem by removing those dependencies. 

     

    Is the sequence of the units in the map file identical to the sequence in which the initialization sections are processed?

     

  9. Posted

    2 hours ago, Stefan Glienke said: 
    
{$APPTYPE CONSOLE}

uses
  Windows;

type
  TFoo = class
    procedure Bar; virtual;
  end;

procedure TFoo.Bar;
begin
  Writeln('broken');
end;

procedure FixedBar(Self: TFoo);
begin
  Writeln('fixed');
end;

var
  f: TFoo;
  p: Pointer;
  n: UINT_PTR;
begin
{$POINTERMATH ON}
  p := @FixedBar;
  WriteProcessMemory(GetCurrentProcess, @PPointer(TFoo)[0], @p, SizeOf(Pointer), n); // 0 is the virtual index of the method to be replaced

  f := TFoo.Create;
  f.Bar;
end.

    The virtual method index can also be found out programmatically.

    What I meant specifically is, how do I find out the index of a method in the VMT?

     

     

     

     

     

  10. Posted

    21 hours ago, Stefan Glienke said:

    When you patch a virtual method you don't need to patch it using the technique to place a jmp into the original code you can directly patch the address in the vmt slot.

    For that you just need to have the index of the virtual method.

    That's very interesting, could you show a small example?

  12. Posted · Edited by A.M. Hoornweg

    Has any of you tried using Bluestacks instead?

    It's an all-in-one Android emulator which emulates an ARM processor.  I'm not using it for development but rather for running some Android apps that aren't available on Windows.

    bluestacks.png

  13. Posted

    16 hours ago, Remy Lebeau said:

    You can increase the column size inline without making a copy and dropping the original.  Firebird allows columns to be altered with minimal overhead if the same type is used and just the size is increased.  Modifications to an existing column will be disallowed if existing data would be lost/truncated, but that is not the case when increasing the size.

     

    However, a PRIMARY KEY cannot be altered, so you have to drop the key first.

     

    http://www.firebirdtest.com/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-tbl.html#fblangref25-ddl-tbl-altraltrcol

     

    Try something like this (untested): 

    
ALTER TABLE channels
DROP CONSTRAINT <NAME_OF_YOUR_PRIMARY_KEY_CONTRAINT>,
ALTER COLUMN paramname TYPE VARCHAR(40) CHARACTER SET ISO8859_1,
ADD CONSTRAINT <NAME_OF_YOUR_PRIMARY_KEY_CONTRAINT> PRIMARY KEY (paramname);

    If you didn't give your primary key constraint an explicit name originally, you can use the system tables to find the auto-generated name that Firebird created (it is in the RDB$CONSTRAINT_NAME field in the RDB$RELATION_CONSTRAINTS system table, see Find all column names that are primary keys in Firebird database).

    Thanks a lot Remy, this works indeed!  But I needed to perform a commit after each step, else it threw an error.

  14. Posted

    13 hours ago, Remy Lebeau said:

    You can increase the column size inline without making a copy and dropping the original.  Firebird allows columns to be altered with minimal overhead if the same type is used and just the size is increased.  Modifications to an existing column will be disallowed if existing data would be lost/truncated, but that is not the case when increasing the size.

     

    However, a PRIMARY KEY cannot be altered, so you have to drop the key first.

     

    http://www.firebirdtest.com/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-tbl.html#fblangref25-ddl-tbl-altraltrcol

     

    Try something like this (untested): 

    
ALTER TABLE channels
DROP CONSTRAINT <NAME_OF_YOUR_PRIMARY_KEY_CONTRAINT>,
ALTER COLUMN paramname TYPE VARCHAR(40) CHARACTER SET ISO8859_1,
ADD CONSTRAINT <NAME_OF_YOUR_PRIMARY_KEY_CONTRAINT> PRIMARY KEY (paramname);

    If you didn't give your primary key constraint an explicit name originally, you can use the system tables to find the auto-generated name that Firebird created (it is in the RDB$CONSTRAINT_NAME field in the RDB$RELATION_CONSTRAINTS system table, see Find all column names that are primary keys in Firebird database).

    Thanks Remy, I'll give it a try and keey you updated!

  15. Posted

    19 hours ago, Dany Marmur said:

    It would help if you supply the error message. I have a theory, but it does not compute 100%, and it's not creative to speculate.

    Also, do you use Isql or an admin tool? I believe that my too "helps me" with step 4. That meaning it will run a series of DDL queries.

     

    Hi Dany,

    the error message said that FB couldn't create the primary key because the column wasn't declared as "not null".   Which I couldn't do, because the new column contains nulls right after creation in step 4. 

    I did the steps one by one in FlameRobin, but when everything works I must re-code it either in Delphi or in InnoSetup (because I have to distribute it as part of a software update).

  16. Posted

    Hello all,

     

    Are there any FB experts here? I could use a little help ...

     

    I need to enlarge the size of a Varchar primary key column in a small but populated Firebird table from 25 to 40 characters. Much to my surprise, that isn't trivial at all.   There are no foreign keys in other tables pointing to this primary key so really, it should be straightforward, shouldn't it?   

     

    The table name is "channels" and the primary key column is "paramname", it was originally declared as "varchar(25) character set iso8859_1 not null primary key".

    So far my trial steps were:  (note that I did a commit after each statement)

     

    //1-Create a temporary column to hold the original data

    ALTER TABLE channels add temp_paramname VARCHAR(40) CHARACTER SET ISO8859_1

     

    //2-Copy the data

    UPDATE channels set temp_paramname=paramname

     

    //3-Delete the old column
    ALTER TABLE channels DROP paramname

     

    // 4-Re-create column "paramname".  The table has records, so I cannot declare it "not null" or "primary key" at this point 
    ALTER TABLE channels add paramname VARCHAR(40) CHARACTER SET ISO8859_1

     

    //5-Populate it with the original data

    UPDATE channels set paramname=temp_paramname

    //6-Now make it primary key - this step fails!

    alter table channels add primary key (paramname)

     

    //7-delete the temp column now...

     

     

     

     

    I'd be grateful for any help.  

  18. Posted

    Hi David,

     

    I'm aware of these workarounds, thanks.

     

    But I'm also aware that a 32 bit process  *can* actually see the 64 bit registry, see  https://docs.microsoft.com/en-us/windows/win32/winprog64/accessing-an-alternate-registry-view . 

     

    And if that weren't the case, the problem could also be solved by putting the tlb importer GUI in a separate process, to be compiled in two versions.

     

     

    It would just be really nice if this feature worked like it's supposed to. 

     

     

    • Like 1

  22. Posted

    Using Wireshark, I can observe how the Delphi IDE queries the DNS for "getit.embarcadero.com" as soon as Delphi tries to install the Android platform.

     

    This tells me that the IDE really uses Getit as the mechanism to retrieve the Android SDK.  Anyway, the DNS server answers with the IP "204.216.225.162".  Then Delphi initiates a TCP connection to that address on port 443. The connection is successful and a TLS connection is initiated.  The server exists and is listening!   A few seconds later, the error message "cannot load data from the server. Please, check your connection status" appears in Delphi.

     

    So... Even though Getit basically works, it seems that the Android SDK is AWOL on the server itself.  

     

    I had installed Delphi from the ISO because I wanted to avoid dependencies on unreliable external sources.  An ISO/DVD is supposed to have a self-contained installer with the correct versions of the dependencies, but the person who composed this ISO really didn't think things through well enough. 

     

    You know, one reason for archiving an ISO is to be able to install the product exactly how it was at the time of the release. That isn't possible if external dependencies are missing or have changed in the mean time.

     

     

     

  23. Posted

    16 hours ago, Clément said:

    Hi,

     

    Have you tried the new patches?
    http://blog.marcocantu.com/blog/2019-august-more-patches-update-getit.html

     

    HTH,

    Clément

     

    No. GetIt itself does work now and shows me lots of libraries, but Delphi 10.3.2 Rio is unable to automatically download/install the Android SDK.

    If anyone buys & Installs Delphi now (from the iso) with the intention of developing for Android, he'll be disappointed.

     

    Regards,Arthur

  24. Posted

    I recently had the case that an update of a third party library "patched" a VCL routine and replaced it with a different one for speed reasons, only the new routine turned out to be buggy. This caused a program of mine to suddenly behave erratically.  It took me and the author of the library quite some time to figure it out...  

     

×