Re: [Lazarus] DOM and GTK 12: how to set encoding?
Marc Santhoff wrote: Hi, I have a DOM model read from a xml file that has no encoding named inside it. The var TXMLDocument.Encoding is empty after the file is loaded. TXMLDocument.Encoding is currently not functional. The XML reader assumes that files without specified encoding are UTF-8 (or UTF-16 if a BOM is present). In your case, however, it appears that the file does not contain non-ASCII characters in literal (they are 'escaped' by character entities). The encoding is not relevant in this case, because character entities are directly converted to Unicode code points. WHen compiling the program for GTK 1 the german umlauts are shown correctly, I assume GTK 1 defaults to system encoding (or so ;). The files have been written in a GUI using the same system encoding (ISO-8859-1). The DOM is based on WideStrings (UTF-16 encoding). When you assign DOM properties to AnsiStrings, the compiler inserts implicit conversions into system encoding. When compiled for GTK 2 the umlauts are not shown corrctly and on the console messages like this appear when handing over strings to gtk widgets: Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_t ext() When the texts are not used as caption but as text inside a memo, the warning differs: Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_val idate (text, len, NULL)' failed and the strings in question are left out up to the next newline. GTK 2 requires UTF-8 everywhere, so implicit conversions inserted by compiler will work correctly only when your system locale is UTF-8. Otherwise, you'll need to manually convert strings using UTF8Encode() and UTF8Decode(). The encoding inside the file löooks like this: Stichw#246;rter: for the Letter ö. How can make GTK 2 show those chars as in GTK 1? Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] function StabBackTraceStr(addr:Pointer):shortstring; - problem with subsequent back traces
Bogusław Brandys пишет: There is a problem with this function. To avoid recursion there is a hack there to point BackTraceStrFunc to system implementation (which only shows addresses in hex).Long back trace which mostly ends with incorrect frame address as I suppose (OpenStabs is returning false for nil address) - thus function pointer is not returned back to lineinfo stabs processing method and next back trace contains only addresses . Right you are. However, many backtraces *start* with an invalid frame: e.g. when you call a virtual method of an object that is already destroyed, you'll likely end up at a random address. This problem is minor if program crashes with exception and stack trace but in other cases , like in bigger program (any Lazarus ones) , ONLY first back trace has useful information (source,line number) attached to it. That eliminates any useful logging like multilog for example. And nobody really is able to know correct stack frames length before calling any of such functions to obtain back trace (that would resolve problem). How we could fix it ? Is this recursion still a subject here ? I fixed one of the causes recently (see exeinfo.pp, rev.12802), but that wasn't enough. In general, code of lineinfo, lnfodwrf and exeinfo has to be checked very carefully to make sure it would not crash at any circumstances. Including possibly unknown/corrupted state of the RTL in case when backtrace is called due to a crash. I have one idea, probably not perfect. How about a function to initialize BackTraceStrFunc : TBackTraceStrFunc; The only way now is to set : BackTraceStrFunc := @SysBackTraceStr; (displays only hex of addresses) Something generic is needed, able to set to StabBackTraceStr if lineinfo unit (option -gl) is used and only to SysBackTraceStr in other case. It might be used also to set to user defined function. That way in any such functions in lcl (DumpExceptionBackTrace,GetStackTrace) or external package (like multilog), we could initialize BackTraceStrFunc to point again to correct function before obtaining stack trace. For me, it looks simpler and better to restore BackTraceStrFunc unconditionally at the end of StabsBackTraceFunc/DwarfBackTraceFunc. Or even better, have it set to stub only for calling GetLineInfo. Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
Michael Van Canneyt пишет: Hello, Is there a reason why the default exception dialog has a cancel button to kill the application ? We often use an exception to signal wrong entry of data or so, because it stops all further processing. If the user then uses the cancel button, the program is simply ended, which is not what we (or better: the users) want. And I imagine many others use this technique. I have overridden the OnException handler of TApplication, so it's no longer a problem, but I was curious as to why this is done like this by default ? I remember discussions on this topic long ago. It was like GTK (GTK 1 at that time) isn't tolerant to exceptions that occur in its signal handlers (read: in LCL and user's code), and it wasn't possible to expect program stability after an exception was raised. That explains the need for 'terminate' button. The things may have changed since then, however. Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Stringgrid woes...
Michael Van Canneyt wrote: ... Is there a reason for the current behaviour, and can it be changed ? With Delphi, I used to check the grid.EditorMode property in OnSetEditText handler, and skip all validations when EditorMode=true. Didn't check this with LCL, but there's a good chance it works. Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Stringgrid woes...
Jesus Reyes wrote: Is this different on Delphi? I would like to improve compatibility if it's not. If OnSetEditText is enough in Delphi to know when editing is finished then I think we should do it also. It appears to be different then. In Delphi, OnSetEditText is called multiple times during editing (with grid.EditorMode=True), and when the editing is complete, it is called once with grid.EditorMode=False. Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Stringgrid woes...
Michael Van Canneyt wrote: Not in delphi 7, I tested ? However, it is called when you set EditorMode explicitly to false. But never by itself. Yep, I was wrong, details tend to become forgotten with time :( But only partially. It is called when you finish editing by pressing Enter, or by moving current cell with the keyboard, or by activating another control. It is not called when you finish editing by mouse click elsewhere in the grid. Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Line Ending FPC/Delphi
Felipe Monteiro de Carvalho wrote:
In my projects I usually have a file with only general constants,
which is added by all others. In this file I add the following
declaration:
{$IFNDEF FPC}
const
LineEnding = #10#13;
{#endif}
In Delphi this constant is called sLineBreak. For compatibility reasons,
it exists in FPC as well. So using sLineBreak allows writing code
without $ifdef's.
Regards,
Sergei
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Zipfiles using Paszlib...
Lee Jenkins wrote: I'm confused. Does TZipper produce pkZIP compatible files or is it zlib based and only called TZipper? Yes, it produces pkZIP compatible files and yes, it uses zlib for compression. .zip file format deals only with overall archive file structure (headers, directories, etc). Each individual file within .zip archive may be compressed using its own method, or even not compressed at all. The most popular compression format used in .zip files is 'deflate', which is handled perfectly well with zlib. The difference with .gz format is only that compressed stream is written without .gz header. Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] flickering on statusbar panel
Michael Van Canneyt wrote: As far as I know, in Delphi the statusbar updates immediatly, contrary to a label. There is a bug in VCL that causes statusbars flicker. It can be fixed by something like not passing WM_ERASEBKGND to DefWindowProc (something like is because it was a long time ago, and I cannot remember exactly). All common controls are doublebuffered natively by Windows, so they shouldn't flicker even without doublebuffering in LCL. Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Linking to an arbitrary DLL (libusb-win32)
Mark Morgan Lloyd wrote:
...
When compiled for Linux I've got a simple unit UsbIf that calls Uwe
Zimmerman's translation of libusb.h which includes
{$linklib usb}
..
procedure usb_set_debug(level: longint);cdecl;external;
On the Windows systems the DLL is libusb0.dll and in principle I've got
.h files etc. available. When I compile I get
Error: Import library not found for usb
..
Error: Undefined symbol _usb_set_debug
It's 20 years since I've played with import libraries, and before I
start tinkering I need to know that I'm not heading off in the wrong
direction.
Having faced with the same problem in the meantime, I deleted the
{$linklib } directive and added library and name to all function
definitions, so your example would look like
procedure usb_set_debug(level: longint);cdecl;external libname name
'usb_set_debug';
The libname constant has to be defined differently for Windows and Linux:
const
{$IFDEF MSWINDOWS}
libname = 'libusb0.dll';
{$ELSE}
libname = 'libusb.so';
{$ENDIF}
Another caveat with libusb-win32 is that LIBUSB_PATH_MAX constant should
be different from the Linux one:
{$IFDEF MSWINDOWS}
const LIBUSB_PATH_MAX = 512;
{$ENDIF}
{$IFDEF LINUX}
const LIBUSB_PATH_MAX = 4097;
{$ENDIF}
Regards,
Sergei
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Finding out the Hostname of the Computer.
Dave Coventry wrote:
...
Can anyone see what I'm doing wrong, or offer an alternative way of
getting the name of the computer?
A simple
result := GetEnvironmentVariable('HOSTNAME');
should do it.
Alternatively, you may read the /etc/hostname file just as you read any
other text file.
Regards,
Sergei
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] XML and memory loss
Bart wrote:
Then how can I free those TDOMNodeList objects? I.o.w. how can I get
access to them?
You just put them into a variable and later call Free:
var
Nodes: TDOMNodeList;
...
Nodes := MyNode.ChildNodes;
writeln(Nodes[0].NodeName);
...
Nodes.Free
I tried that, and it wordk like a charm.
However can I use that approach if I want to create more complex XML files?
Eventually I want someting like this:
?xml version=1.0?
root
versionfoo bar version 0.0.1/version
children
child id=0001
fooBart/foo
barme, myself and I/bar
/child
child id=0002
fooBob/foo
barblah/bar
/child
children/
/root
In general, any tree can be built using only the AppendChild method.
Just put necessary nodes in variables. Here is your example:
var
doc: TXMLDocument;
root, tmp, children, foo, bar: TDOMNode;
begin
doc := TXMLDocument.Create;
root := doc.CreateElement('root');
doc.AppendChild(root);
tmp := doc.CreateElement('version');
tmp.AppendChild(doc.CreateTextNode('foo bar version 0.0.1'));
root.AppendChild(tmp);
children := doc.CreateElement('children');
root.AppendChild(children);
// first child
tmp := doc.CreateElement('child');
tmp['id'] := '0001';
foo := doc.CreateElement('foo');
foo.AppendChild(doc.CreateTextNode('Bart'));
tmp.AppendChild(foo);
bar := doc.CreateElement('bar');
bar.AppendChild(doc.CreateTextNode('me, myself and I'));
tmp.AppendChild(bar);
children.AppendChild(tmp);
// second child
tmp := doc.CreateElement('child');
tmp['id'] := '0002';
foo := doc.CreateElement('foo');
foo.AppendChild(doc.CreateTextNode('Bob'));
tmp.AppendChild(foo);
bar := doc.CreateElement('bar');
bar.AppendChild(doc.CreateTextNode('blah'));
tmp.AppendChild(bar);
children.AppendChild(tmp);
end;
Regards,
Sergei
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] XML and memory loss
Bart wrote: ... This file is more or less as I excpected it to be (i would think it would include the encoding=utf-8). Currently changing the encoding is not supported, and files are always written in utf-8 encoding. According to the XML specs, files without encoding label are read as utf-8, so this is by design. The problem is, that for every child I create and append, I loose 4 blocks of memory (60 bytes for these 4 blocks) (I used the heaptrace option with compilation). The memory leak is caused by using the ChildNodes property. Each time you use it, a new TDOMNodeList object is created, which must be eventually destroyed by calling Free. The FCL DOM implementation does not offer automatic memory management here, unlike other implementations. Some time ago I updated the English page of Wiki tutorial to reflect this fact. In your case, ChildNodes.Item[0] can be replaced by FirstChild, which will return exactly the same node. Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] XML and memory loss
Jesus Reyes wrote: By the way, and taking the fact that xml files are stored always in utf-8 encoding it's surprising that for example XMLConfig doesn't have a way to set a value which is already utf-8 encoded. so, any change to add a methods that take utf-8 encoded strings as arguments?, this way it could ve avoided unnecesary conversions. The writer wasn't utf-8 capable at the time of writing TXMLConfig. Even if you add utf-8 methods to TXMLConfig, certain conversions will stay because underlying DOM is WideString-based. After adding utf-8 to the writer, I've chosen to write a new unicode-enabled config class instead of modifying the old one and risk breaking the existing code. The new component is in the xmlconf unit, and it takes WideString arguments. Regards, Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] (patch) File Open dialog start in the directory of active source file
Hello,
This tiny patch implements a feature which can be found in Programmer's
Notepad, and which proves to be very useful (at least to me).
It makes the File Open dialog open in the directory of the file which is
active in source notebook. Thus, each opened file acts as a filesystem
bookmark, and whenever you work with sources from several directories,
efforts needed to navigate in File Open dialog are greatly reduced.
Maybe this feature must be made configurable (I am ready to do it, let
me know if I should), but honestly I cannot imagine any reason to
disable it.
Best regards,
Sergei
Index: main.pp
===
--- main.pp (revision 15370)
+++ main.pp (working copy)
@@ -2379,10 +2379,24 @@
AFilename: string;
I: Integer;
OpenFlags: TOpenFlags;
+ PageIndex: Integer;
+ ActiveSrcEdit: TSourceEditor;
+ ActiveUnitInfo: TUnitInfo;
begin
OpenDialog:=TOpenDialog.Create(nil);
try
InputHistories.ApplyFileDialogSettings(OpenDialog);
+
+if Assigned(SourceNotebook.Notebook) then
+begin
+ PageIndex := SourceNoteBook.Notebook.PageIndex;
+ if PageIndex = 0 then
+ begin
+GetUnitWithPageIndex(PageIndex,ActiveSrcEdit,ActiveUnitInfo);
+if ActiveUnitInfo.Filename '' then
+ OpenDialog.InitialDir := ExtractFilePath(ActiveUnitInfo.Filename);
+ end;
+end;
OpenDialog.Title:=lisOpenFile;
OpenDialog.Options:=OpenDialog.Options+[ofAllowMultiSelect];
OpenDialog.Filter:=dlgAllFiles+' ('+GetAllFilesMask+')|'+GetAllFilesMask
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] (patch) File Open dialog start in the directory of active source file
Michael Van Canneyt wrote: I think it should definitely be made configurable. I much prefer the notion of the 'currently active' directory. I have many files open, in many directories. Often the current file (rtl/vcl/fcl whatever files, opened with ctrl-enter on a unit name) will be in the wrong directory, which is not part of the project. Correct, in this case you need an extra click to activate a file which is in the 'right' directory. But once you have some files opened, any other within their dirs is opened with four clicks at most. The intent is exactly to handle 'random-order-multi-directory' cases. A downside of 'currently active' directory is that it changes whenever you need to open something outside of it. When I started using Programmer's Notepad, I didn't feel like I have to change my habits to accomodate with this feature. Now I feel uncomfortable using other editors... Sergei ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
