Re: [Lazarus] TChart - How to read first/last values from DbChartSource after zoom
http://bugs.freepascal.org/view.php?id=24422 Gabor -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Regressions in GTK2 interface ?
Hi all I have the same problem as Juha with the menu icons having dissapeared. This is on 64 bit Mageia Linux with the latest lazarus and fpc from svn. Also I have noticed that in the object inspector if I try to change the colour of a component, the list of colours is corrupted so that the boxes with the colours all look the same, almost as though they were drawn with ink and someone has spilled water on it. Regards Tim -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] windows rt
2013/5/12 Michael Van Canneyt > > > On Sun, 12 May 2013, Sven Barth wrote: > > On 12.05.2013 14:19, Felipe Monteiro de Carvalho wrote: >> >>> ok if you allocate the memory using functions from the Windows API which are available for WinRT) >>> >>> From what I read what is available for allocating memory in WinRT is >>> malloc from the Visual C RTL. >>> >> >> Yes, nevertheless the RTL needs to be adjusted for this, because the heap >> manager uses the HeapAlloc function from kernel32.dll and not the Visual C >> RTL. >> > > if you use cmem, it should ? > > > This is the reason Delphi does not support windows RT at the moment. > They are too deeply rooted in the Win32 API, and they too must 'rewrite' > the RTL. > > It will be interesting to see who will be there first :-) > > Sounds like the situation on *nix where some targets use the syscall api (like current win32 and win64) and some the libc api (like win RT). Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to disable the assembler window on Linux?
Any update? as for the stepping out (4), I *guess* that eithur: - fpc or the linker were changed and the debug info is incorrectly generated (Though I did not see any commit with a log message, suggesting work on this) - Something changed in GDB On 11/05/2013 12:20, Martin wrote: On 11/05/2013 05:11, silvioprog wrote: 2013/5/8 Martin mailto:laza...@mfriebe.de>> You did not answer this. If you hit a breakpoint, do you still get the asm? Well, Not to be difficult, but the answer below relates to the question above in which way? I am glad for you to report any issue you have with debugging. There is still much improvement to be done, and every bit of feedback helps. But please, lets do them 1 by 1: 1) asm window, when hitting a breakpoint. I believe that is solved? 2) asm when stopping on a signal. Acknowledged, but no immediate solution available. 3) You have not reported yet, but you may still: hitting an exception via assert or raise, shows the code in the caller (one stackframe down). Acknowledged (this is because the rtl is compiled with optimization) 4) your code below (f8 to different unit): 5) your mention below of strings In Windows, if I put: procedure TForm1.Button1Click(Sender: TObject); var s: string; begin s := 'abc'; << Break point here (F5) // line 1 ShowMessage(s); // line 2 end; and I use Step Over (F8), the cursor go to "line 2", but the same code in Linux, go to GTK units. See: 1 - http://imagebin.org/257292 2 - http://imagebin.org/257294 (after first F8) I don't know debug code in assembler. I'm pretty sure the problem is in the IDE, because in Linux/GTK it is not able to debug a simple string variable. "I don't know debug code in assembler." Neither image shows the assembler. Nor does your description mention it. Btw the unit it goes to in the pic is not GTK(LCL-widgetset), but LCL. I asked again (because *not* following the below may be typical reasons for the behaviour): - Compiled with smart-linking disabled - Compiled with either -O0 or -O1 (Optimize zero or one) Also: - You use the default keymap for debug stuff? http://imagebin.org/257326 - you did not hold shift by accident (shift f8 is step out of the current procedure and would do exactly what you observed) If none of the above: log file please - 5) "because in Linux/GTK it is not able to debug a simple string variable." In which way? - Note there are utf8 issues. they display as \x209... and similar. (reported on mantis) - There is a known issue with accessing chars by index "s[1]" GDB can not differentiate between pchar and string (1 and 0 based index), and also there is no way for the IDE to get the diff from gdb. Therefore it is experted that the IDE shows "PChar: 'm' String: 'o' " or similar. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TFPImageCanvas alphablend
Hi, I loaded a PNG with alpha channel (transparent background) into a TFPMemoryImage, then created a TFPImageCanvas, filled its background with red color, then used TFPImageCanvas.Draw method to draw the original image on top of red background. The image was drawn on canvas but its backgrodund is black. Does anyone know a way to create a TFPMemoryImage created by composing one or more PNGs without losing the alpha channel?. I know this can be done with TBgraBitmap or AggPass, but I cannot use then right now. Regards, -- Leonardo M. Ramé http://leonardorame.blogspot.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] windows rt
On Sun, 12 May 2013, Sven Barth wrote: On 12.05.2013 14:19, Felipe Monteiro de Carvalho wrote: ok if you allocate the memory using functions from the Windows API which are available for WinRT) From what I read what is available for allocating memory in WinRT is malloc from the Visual C RTL. Yes, nevertheless the RTL needs to be adjusted for this, because the heap manager uses the HeapAlloc function from kernel32.dll and not the Visual C RTL. if you use cmem, it should ? Also, does anyone know if the executable format at least in win rt is the same? pe format and available in both executable and dll forms? It's the same. This part is really good! So one could theorically use the win32 binutils and just copy the existing RTL and delete all calls to the WinAPI and substitute it to Visual C RTL calls to make a quick and dirty port ... The big work of a WinRT port of FPC is exactly this substitution of API calls. Adding a new target to the compiler and the build utilities is easy. Implementing the RTL is the hard one and you'll have to do that no matter whether you do a "quick and dirty" port or a real one. In both cases you'll need to research the correct function to use and the correct way to pass in or retrieve data. This is the reason Delphi does not support windows RT at the moment. They are too deeply rooted in the Win32 API, and they too must 'rewrite' the RTL. It will be interesting to see who will be there first :-) Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] windows rt
On 12.05.2013 14:19, Felipe Monteiro de Carvalho wrote: ok if you allocate the memory using functions from the Windows API which are available for WinRT) From what I read what is available for allocating memory in WinRT is malloc from the Visual C RTL. Yes, nevertheless the RTL needs to be adjusted for this, because the heap manager uses the HeapAlloc function from kernel32.dll and not the Visual C RTL. Also, does anyone know if the executable format at least in win rt is the same? pe format and available in both executable and dll forms? It's the same. This part is really good! So one could theorically use the win32 binutils and just copy the existing RTL and delete all calls to the WinAPI and substitute it to Visual C RTL calls to make a quick and dirty port ... The big work of a WinRT port of FPC is exactly this substitution of API calls. Adding a new target to the compiler and the build utilities is easy. Implementing the RTL is the hard one and you'll have to do that no matter whether you do a "quick and dirty" port or a real one. In both cases you'll need to research the correct function to use and the correct way to pass in or retrieve data. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] windows rt
On Sat, May 11, 2013 at 10:49 AM, Sven Barth wrote: > must use the GNU binutils). Your code must not call the RTL in any way > however (this includes strings, dynamic arrays and classes; objects would be Umm, that's too nasty. I surely need strings, arrays and classes, or else one must write some kind of useless spaguetti code. So I guess it is a no way for Windows Store for now. > ok if you allocate the memory using functions from the Windows API which are > available for WinRT) >From what I read what is available for allocating memory in WinRT is malloc from the Visual C RTL. >> Also, does anyone know if the executable format at least in win rt is the >> same? pe format and available in both executable and dll forms? > It's the same. This part is really good! So one could theorically use the win32 binutils and just copy the existing RTL and delete all calls to the WinAPI and substitute it to Visual C RTL calls to make a quick and dirty port ... Anyway, the amount of work needed to support it looks larger than the platform is worth for me ... so I'll just go back to porting my app to Android and forget Windows Store for now. I was mostly interrested in the $100 bucks that MS is willing to pay per application developed: http://www.zdnet.com/microsoft-offers-developers-cash-to-write-windows-8-apps-712851/ But now I noticed it is only for people that live in the United States =( So there is no hurry to support a platform with currently nearly zero market share. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TAChart with AggPas drawer
Hi, http://wiki.lazarus.freepascal.org/TAChart_documentation#AggPas_drawer Based on the above URL, it states that "there are some limitations in TAChart support". Unfortunately there is no content or links listing those limitations. Anybody no where I could find this information? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
