* * *

Recent Posts

Pages: [1] 2 3 ... 10
1
LCL / Re: TValueListEditor - A Cell is cleared after sorting
« Last post by Bart on Today at 10:57:59 pm »
Delphi 7 has InsertRow(Key: string; Value: String; Append: Boolean);
The 3rd parameter controls if insert is before or after the current row.

@wp: thanks for the patch in the bugtracker. I'll take a look when I have time.

Bart
2
https://www.freepascal.org/docs-html/current/prog/progsu9.html#x16-150001.2.9

{$CODEALIGN VARMAX=1}{$CODEALIGN RECORDMAX=1}{$CODEALIGN LOCALMAX=1}
Usually the compiler will pick natural alignment for records and its members. (AND you specified {$align on}, which forces that...) The above should prevent that, but in my experience not on all platforms: some CPU's rely on naturally aligned data.
If this works for you, note that you just slowed down your code *a lot*!. (With the exception of 8 bit processors)

Also note that half of the switches here are duplicates and align on can even clash with other alignment settings.

Thank you Thaddy, that was useful.  No matter the settings, it still insists on 8 byte alignment.  That's an improvement.  There doesn't seem to be a way to convince the compiler to align those arrays on a byte or word boundary, which is unfortunate.
There shouldn't be any slow down because the natural alignment of a (single byte) character array is byte alignment (they are accessed byte at a time, as long as it is that way, it doesn't make any difference.)  I'm not changing the alignment of any ordinal types (those would definitely be affected) or code for that matter.

I'm not worried about telling the compiler multiple times what I want.  I want to be certain that nothing resembling managed types gets in the code.

Add

Code: Pascal  [Select]
  1. writeln(sizeof(messages));

Those literals are only part of the namespace of the record, they are not members. Moreover afaik literals are assignment compatible to ansistrings so have a record at negative offset, which contains non-byte entities.
Yes, I was aware of that but, I was throwing stuff at the compiler to see what, if anything, made a difference .  I do appreciate your pointing it out, though. Thank you.  Just FYI, the literals are still kept as plain literals, no size is present in the executable file (at least not in Windows.)  I guess the compatibility is done at runtime through library code. 

8 byte alignment is an improvement over 16 byte alignment.  That's good enough for most cases.
3
I overlooked that. Indeed. They are literals, not members.
Remove the consts in the record and my above advice applies. Although note that shortstrings also have a (bytesized) negative offset. the length byte at index 0.
For it to work properly you probably need to use fixed length arrays of AnsiChar as record members.
And in the case of shortstring, also give them the proper length: shortstring[22]; etc. if they are record members.Otherwise the compiler will reserve 256 bytes for every shortstring.
4
Add

Code: Pascal  [Select]
  1. writeln(sizeof(messages));

Those literals are only part of the namespace of the record, they are not members. Moreover afaik literals are assignment compatible to ansistrings so have a record at negative offset, which contains non-byte entities.
5
well, this is weird.  This app was old and if I turn on the newer project option for DPI awareness, guess what?  It does not corrupt the menus.
Why on earth the windows photo viewer would have anything to do with this is super odd.
It's only when the path sent to shellexecute or opendocument is a image, anything else is fine.
6
Why don't you do it in the Lazarus way?
Code: Pascal  [Select]
  1. uses
  2.   LCLIntf;
  3. ...
  4.   OpenDocument(fpath);

I tried that already and it does the same thing, on windows Opendocument must call shellexecute.
7
https://www.freepascal.org/docs-html/current/prog/progsu9.html#x16-150001.2.9

{$CODEALIGN VARMAX=1}{$CODEALIGN RECORDMAX=1}{$CODEALIGN LOCALMAX=1}
Usually the compiler will pick natural alignment for records and its members. (AND you specified {$align on}, which forces that...) The above should prevent that, but in my experience not on all platforms: some CPU's rely on naturally aligned data.
If this works for you, note that you just slowed down your code *a lot*!. (With the exception of 8 bit processors)

Also note that half of the switches here are duplicates and align on can even clash with other alignment settings.
Code: Pascal  [Select]
  1. {$MODE OBJFPC                      }
  2.  
  3. {$MODESWITCH     ADVANCEDRECORDS   }
  4. {$MODESWITCH     TYPEHELPERS       }
  5. {$MODESWITCH     ALLOWINLINE       }
  6. {$MODESWITCH     RESULT            }  // Is already on in objfpc mode
  7. {$MODESWITCH     PROPERTIES        }  // is already on in objfpc mode
  8.  
  9. {$MODESWITCH     ANSISTRINGS-      }  // default is already H- in objfpc mode: the standard type is shortstring
  10. {$MODESWITCH     AUTODEREF-        }  // is already off in objfpc mode
  11. {$MODESWITCH     UNICODESTRINGS-   }  // is already off in objfpc mode: the standard is shortstring
  12. {$MODESWITCH     POINTERTOPROCVAR- }  // is already off in objfpc mode
  13.  
  14. {$LONGSTRINGS    OFF               }  // is already off in objfpc mode: standard is shortstring
  15. {$WRITEABLECONST ON                }
  16. {$TYPEDADDRESS   ON                }
  17. {$ALIGN          ON                }  // forces natural alignment...
Better clean up a bit....
8
Why don't you do it in the Lazarus way?
Code: Pascal  [Select]
  1. uses
  2.   LCLIntf;
  3. ...
  4.   OpenDocument(fpath);
9
ok, I will give that a shot.
10
Hi there,

Here is something I would try, I'd explicitly set the verb (second parameter.)  Passing nil makes things somewhat unpredictable and dependent on whatever is specified in the registry.

I don't know if that will solve the problem but, it is the first thing I'd try.

HTH.
Pages: [1] 2 3 ... 10

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus