You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(60) |
Jul
(35) |
Aug
(32) |
Sep
(5) |
Oct
(5) |
Nov
(58) |
Dec
(34) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(114) |
Feb
(184) |
Mar
(153) |
Apr
(90) |
May
(153) |
Jun
(59) |
Jul
(24) |
Aug
(43) |
Sep
(17) |
Oct
(34) |
Nov
(11) |
Dec
(204) |
2007 |
Jan
(84) |
Feb
(119) |
Mar
(38) |
Apr
(28) |
May
(52) |
Jun
(105) |
Jul
(64) |
Aug
(67) |
Sep
(14) |
Oct
(3) |
Nov
(28) |
Dec
(55) |
2008 |
Jan
(228) |
Feb
(55) |
Mar
(30) |
Apr
(30) |
May
(15) |
Jun
(20) |
Jul
(12) |
Aug
(3) |
Sep
(13) |
Oct
(54) |
Nov
(35) |
Dec
(35) |
2009 |
Jan
(19) |
Feb
(20) |
Mar
(34) |
Apr
(4) |
May
(60) |
Jun
(25) |
Jul
(16) |
Aug
(51) |
Sep
(19) |
Oct
(62) |
Nov
(21) |
Dec
(12) |
2010 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(23) |
Jun
(13) |
Jul
(1) |
Aug
(40) |
Sep
(18) |
Oct
(21) |
Nov
(26) |
Dec
(34) |
2011 |
Jan
(17) |
Feb
(23) |
Mar
(1) |
Apr
(10) |
May
(1) |
Jun
(5) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(43) |
2012 |
Jan
(5) |
Feb
(19) |
Mar
(6) |
Apr
(24) |
May
(39) |
Jun
(83) |
Jul
(29) |
Aug
(36) |
Sep
(64) |
Oct
(55) |
Nov
(12) |
Dec
(7) |
2013 |
Jan
(17) |
Feb
(10) |
Mar
(37) |
Apr
(27) |
May
(13) |
Jun
(9) |
Jul
(7) |
Aug
(61) |
Sep
(23) |
Oct
(23) |
Nov
(30) |
Dec
(16) |
2014 |
Jan
(23) |
Feb
(13) |
Mar
(9) |
Apr
(17) |
May
(2) |
Jun
(11) |
Jul
(2) |
Aug
|
Sep
(9) |
Oct
(24) |
Nov
(2) |
Dec
(14) |
2015 |
Jan
(6) |
Feb
(4) |
Mar
(17) |
Apr
|
May
(7) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
(21) |
Nov
(6) |
Dec
(2) |
2016 |
Jan
(4) |
Feb
(2) |
Mar
(7) |
Apr
(3) |
May
(11) |
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1
(2) |
2
|
3
|
4
(4) |
5
(1) |
6
(6) |
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
(3) |
21
(6) |
22
|
23
(2) |
24
(4) |
25
(2) |
26
|
27
(1) |
28
|
29
|
30
(1) |
31
(2) |
|
|
|
|
From: John L. <jla...@gm...> - 2009-03-06 03:07:04
|
On Wed, Mar 4, 2009 at 4:01 AM, lostgallifreyan <los...@gm...> wrote: >> >>I would load the original as a wxImage and convert it to a wxBitmap >>for drawing, saving both of these. If the zoom changes, use the >>wxImage functions to rescale into the same wxBimap and use this to >>draw into your DC. That way your wxBitmap is ready to go when it comes >>time to paint. If you plan to zoom way in or the image is huge you may >>want to crop the wxImage to a temporary wxImage of the size and >>position of the scrolled window before scaling it, then create the >>wxBitmap for drawing, but note that you will have to do this in real >>time for scrolling. >> > > Nice, I'll try it. It's close to what I had in mind too.The bit about 'saving' both the wxImage and wxBitmap puzzles me though, you mean to file on disk, or to a holding variable at runtime? (I guess latter). Also, if I opt for a crude pixel resize, is there a way that doesn't need to use the wxImage? (Pixel resize is fast, and adequate for this, probably.) I'll still likely use the wxImage though, because the image IS huge, I'll definitely want to crop it if it works fast. (1.2 GHz ITX board, running W98 SE). > Both the original unscaled and uncropped wxImage and the scaled/cropped wxBitmap are in memory. You can also try using wxDC::SetUserScale() IIRC. Regards, John |
From: John L. <jla...@gm...> - 2009-03-06 02:58:58
|
I don't know much, if anything, about wxHtmlEasyPrinting. You can try posting to the wxWidgets wx-users mailing list for help since the HTML code should be the same in wxLua as it is in C++. Good luck, John On Thu, Mar 5, 2009 at 12:03 PM, Éjjeli Őrjárat <ejj...@gm...> wrote: > Hello! > > I have a little problem again with wxHtmlEasyPrinting. I was able to > everything, except one thing - I want to skip to a new page after some > lines. I have to print bills, so after the header and 6-7 table row I want > to skip to page 2. I don't know how can I do this.... My basic idea was to > use a table, but I was unable to set up it's height. width works, height > isn't... Is there any solution to do this? > > Another thing I saw that :SetHeader("@PAGENUM@. page") doesn't work. On > every page it prints 1. page... IS this a bug or I misunderstood something? > > I hope somebody can answer these questions, because it's important to me > (mainly the first). > > Thanks: > > Attila > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > wxlua-users mailing list > wxl...@li... > https://lists.sourceforge.net/lists/listinfo/wxlua-users > > |
From: Éjjeli Ő. <ejj...@gm...> - 2009-03-05 17:03:41
|
Hello! I have a little problem again with wxHtmlEasyPrinting. I was able to everything, except one thing - I want to skip to a new page after some lines. I have to print bills, so after the header and 6-7 table row I want to skip to page 2. I don't know how can I do this.... My basic idea was to use a table, but I was unable to set up it's height. width works, height isn't... Is there any solution to do this? Another thing I saw that :SetHeader("@PAGENUM@. page") doesn't work. On every page it prints 1. page... IS this a bug or I misunderstood something? I hope somebody can answer these questions, because it's important to me (mainly the first). Thanks: Attila |
From: lostgallifreyan <los...@gm...> - 2009-03-04 09:01:14
|
John Labenski <jla...@gm...> wrote: (04/03/2009 07:08) >-- YOU MUST DELETE THE PEN and COLOUR! > local c = wx.wxColour(255,0,0) > local p = wx.wxPen(c,1,wx.wxSOLID) >> DC:SetPen(p) > p:delete() > c:delete() >> DC:DrawLine(0,0,600,600) >> DC:delete() >> end Good, that is exactly what I had in mind, and is why I asked. The way I had it appears lots of times found via Google but I asked because I didn't trust it. >> Why does it need s status bar? It still borks and displays nothing without that being there, and I still can't see why.. > >Move FRAME:Show(true) to the end of the main() function, this forces a >refresh and everything will be laid out by then. > I want to show the frame first, so something can be seen (frame, messages during data load), so maybe force frame refresh directly? I tried FRAME:Refresh() at the end of Main() but that didn't work. I'll want a status bar anyway, but solving this would let me choose some other time. >> Is there a way to make the BITMAP draw once and still work, so I can delete it once it's drawn to the DC for the CHART panel? Is this even in line with the advice on deleting large bitmaps to save resources in MSW? > >No, you have to repaint it every time a wxPaintEvent is sent. This is >normal for GUI programs and even if somebody else drew it for you it'd >still have to store the bitmap. Ok, I realised that soon after writing, it has to be there so any motion of the image has a source to redraw from too. >You should also add a wx.wxEVT_ERASE_BACKGROUND handler that does >nothing, the same as event:Skip(false), to reduce flicker. > Already done, that was first thing after posting once I saw the flicker, I'd already found descriptions of ways to reduce it. >> And, why DC:delete() not DC:Delete() like XYZ:Refresh() or ABC:Show()...? :) Small case-sensitive gotchas like this are one thing that really makes it tough to debug stuff for newcomers. > >"delete" is a reserved word in C++ so it cannot be a function name. >Therefore, wxLua can add it as a function to the userdata without any >worries that we will hide any existing functions. > Ok. >> If the code is now correct, I want to focus on scaling, so should I do this by converting the loaded bitmap to a wxImage() or would it be faster just to load prescaled bitmaps? If the former, can you give me a minimal template for building the needed conversions into the current code? I can convert to image but I'm not clear at what point the image should be deleted after reconversion to bitmap, or even how to reconvert it. > >I would load the original as a wxImage and convert it to a wxBitmap >for drawing, saving both of these. If the zoom changes, use the >wxImage functions to rescale into the same wxBimap and use this to >draw into your DC. That way your wxBitmap is ready to go when it comes >time to paint. If you plan to zoom way in or the image is huge you may >want to crop the wxImage to a temporary wxImage of the size and >position of the scrolled window before scaling it, then create the >wxBitmap for drawing, but note that you will have to do this in real >time for scrolling. > >> You mentioned cropping. This sounds good if it allows a speed gain by avoiding having to draw the whole of a large image. Will it do that though? I imagine that the dragging of the image will cause this image crop and display to occur with every pixel-shift of motion, and not be fast at all. > >I have had success with doing what I mentioned above, it has been fast enough. > >Hope this helps, > John > Nice, I'll try it. It's close to what I had in mind too.The bit about 'saving' both the wxImage and wxBitmap puzzles me though, you mean to file on disk, or to a holding variable at runtime? (I guess latter). Also, if I opt for a crude pixel resize, is there a way that doesn't need to use the wxImage? (Pixel resize is fast, and adequate for this, probably.) I'll still likely use the wxImage though, because the image IS huge, I'll definitely want to crop it if it works fast. (1.2 GHz ITX board, running W98 SE). I've worked out the scaling from fix data to map and shown an accurate overlay, and my next step will be to do colour coding for the track to indicate speed. Gradients based on the resistor colour code. :) This is ok from 0 to 9 miles per hour, but I'll have to think about what to do from 10 to 19, etc... Thicker lines, maybe different styles if they show up ok. I'll view more data that way than by scaling the image so I'll go with that first. For neat panning of a large or zoomed image using cropped sub-sections, it could get complex, like the Google maps method of loading unseen tiles in advance beyond the viewable area. I won't take that on unless it looks like I'll need to. I might just allow a way to point at something and request a momentary zoom of a preset area centred on said point. Much simpler, and more immediate. |
From: lostgallifreyan <los...@gm...> - 2009-03-04 08:16:08
|
John Labenski <jla...@gm...> wrote: (04/03/2009 07:14) > >On Sat, Feb 28, 2009 at 4:00 PM, lostgallifreyan ><los...@gm...> wrote: >> >> There's definitely something wrong though, if you run this and drag a lot of files, some bizarrely large co-ordinates are reported, and sometimes it will even crash wxLua (Shell32.dll in W98 SE running W95 shell, (W98-Lite)). I can repeat the errors but I have no idea what it is about the file names or file counts, or positions on screen, or anything else that might be causing the trouble. It seems to work fine for up to ten files or so. > >I can't reproduce this. I can drop 975 files repeatedly without any problems. > >Regards, > John > No strangely large values for the drop position? I often see them, with large file counts. 10137 seems to be constant for X when it happens, the Y value is variable but is huge, 13nnnnnn, with first n usually 6, sometimes 7. No idea what it means though. I managed to crash it with several thousand files, this time with User.exe. WXLUA caused a general protection fault in module USER.EXE at 0004:00005ff0. Registers: EAX=5002fffc CS=17a7 EIP=00005ff0 EFLGS=00000e16 EBX=00008070 SS=4b9f ESP=0000806c EBP=00008088 ECX=00007fd7 DS=66d7 ESI=0002ffac FS=0000 EDX=8df216b7 ES=1d57 EDI=0000fffe GS=0000 Bytes at CS:EIP: f3 a5 73 03 46 47 a4 fc eb 08 fc d1 e9 f3 a5 73 Stack dump: 00520043 17b707bc 0052fffe 00001d57 000066d7 001d0030 00001d57 0eee8100 fffe0082 66d70000 00e55348 003a000b 50022080 0043ffff 816c1d57 539f8132 I don't know if those messages have any use for you but it's here in case it does. That was from a drop of 3608 files. Pointless really, but when it happens with a drop of around thirty it is more interesting. It seemed to matter which thirty or so, but the patterns made by the possible selections, plus the specific conditions of my OS, make it highly unlikely that any useful consistency can be found, except the unusual values of those X and Y co-ordinates, maybe. |
From: John L. <jla...@gm...> - 2009-03-04 07:14:43
|
On Sat, Feb 28, 2009 at 4:00 PM, lostgallifreyan <los...@gm...> wrote: > > There's definitely something wrong though, if you run this and drag a lot of files, some bizarrely large co-ordinates are reported, and sometimes it will even crash wxLua (Shell32.dll in W98 SE running W95 shell, (W98-Lite)). I can repeat the errors but I have no idea what it is about the file names or file counts, or positions on screen, or anything else that might be causing the trouble. It seems to work fine for up to ten files or so. I can't reproduce this. I can drop 975 files repeatedly without any problems. Regards, John |
From: John L. <jla...@gm...> - 2009-03-04 07:08:20
|
On Sun, Mar 1, 2009 at 3:22 PM, lostgallifreyan <los...@gm...> wrote: > > First, the code, in FULL because the one thing that made my day most difficult is snippets out of context. So much easier if a copy/paste of a working example can be had, then debugging is simple, focus on what change breaks something. For small examples I see no better way than this.. > > function main() > FRAME=wx.wxFrame(wx.NULL,-1,"GPS Plot",wx.wxDefaultPosition,wx.wxSize(1024,768),wx.wxDEFAULT_FRAME_STYLE) > FRAME:Centre() FRAME:Show(true) > FRAME:CreateStatusBar() > > BITMAP=wx.wxBitmap("../Charts/Ashton Court.gif",wx.wxBITMAP_TYPE_GIF) > local X,Y=BITMAP:GetWidth(),BITMAP:GetHeight() > SCROLL=wx.wxScrolledWindow(FRAME,-1) SCROLL:SetScrollbars(1,1,X,Y) > CHART=wx.wxPanel(SCROLL,-1,wx.wxPoint(0,0),wx.wxSize(X,Y)) > > CHART:Connect(wx.wxEVT_LEFT_DOWN,OnLeftDown) > CHART:Connect(wx.wxEVT_MOTION,OnMotion) > CHART:Connect(wx.wxEVT_PAINT,OnPaint) > end > > --==================== Mouse Handling ====================-- > > MX,MY,VX,VY=0,0,0,0 > > function OnLeftDown(event) > MX,MY,VX,VY=wx.wxGetMousePosition():GetX(),wx.wxGetMousePosition():GetY(),SCROLL:GetViewStart() > end > > function OnMotion(event) > if event:LeftIsDown() then > SCROLL:Scroll(VX+MX-wx.wxGetMousePosition():GetX(),VY+MY-wx.wxGetMousePosition():GetY()) > end > end > > --==================== Track Drawing =====================-- > > function OnPaint(event) > local DC=wx.wxPaintDC(CHART) > DC:DrawBitmap(BITMAP,0,0,false) -- YOU MUST DELETE THE PEN and COLOUR! local c = wx.wxColour(255,0,0) local p = wx.wxPen(c,1,wx.wxSOLID) > DC:SetPen(p) p:delete() c:delete() > DC:DrawLine(0,0,600,600) > DC:delete() > end > > --==========================================================-- > > main() > > > > The questions: > Why does it need s status bar? It still borks and displays nothing without that being there, and I still can't see why.. Move FRAME:Show(true) to the end of the main() function, this forces a refresh and everything will be laid out by then. > Is there a way to make the BITMAP draw once and still work, so I can delete it once it's drawn to the DC for the CHART panel? Is this even in line with the advice on deleting large bitmaps to save resources in MSW? No, you have to repaint it every time a wxPaintEvent is sent. This is normal for GUI programs and even if somebody else drew it for you it'd still have to store the bitmap. You should also add a wx.wxEVT_ERASE_BACKGROUND handler that does nothing, the same as event:Skip(false), to reduce flicker. > Is it wise to expand the OnPaint() function to assign the wxPen and wxColour to variables on creation so I can delete them individually? I'm not clear as to whether they are orphaned and consuming resources after the DC:delete(). I do suspect that something persists, as after a few tens of loads in a session, the script was failing to draw the chart, only the line. You MUST always delete these, see above and the docs, http://wxlua.sourceforge.net/docs/wxlua.html, and search for "Must delete". > And, why DC:delete() not DC:Delete() like XYZ:Refresh() or ABC:Show()...? :) Small case-sensitive gotchas like this are one thing that really makes it tough to debug stuff for newcomers. "delete" is a reserved word in C++ so it cannot be a function name. Therefore, wxLua can add it as a function to the userdata without any worries that we will hide any existing functions. > If the code is now correct, I want to focus on scaling, so should I do this by converting the loaded bitmap to a wxImage() or would it be faster just to load prescaled bitmaps? If the former, can you give me a minimal template for building the needed conversions into the current code? I can convert to image but I'm not clear at what point the image should be deleted after reconversion to bitmap, or even how to reconvert it. I would load the original as a wxImage and convert it to a wxBitmap for drawing, saving both of these. If the zoom changes, use the wxImage functions to rescale into the same wxBimap and use this to draw into your DC. That way your wxBitmap is ready to go when it comes time to paint. If you plan to zoom way in or the image is huge you may want to crop the wxImage to a temporary wxImage of the size and position of the scrolled window before scaling it, then create the wxBitmap for drawing, but note that you will have to do this in real time for scrolling. > You mentioned cropping. This sounds good if it allows a speed gain by avoiding having to draw the whole of a large image. Will it do that though? I imagine that the dragging of the image will cause this image crop and display to occur with every pixel-shift of motion, and not be fast at all. I have had success with doing what I mentioned above, it has been fast enough. Hope this helps, John |
From: lostgallifreyan <los...@gm...> - 2009-03-01 20:22:18
|
>This next wxPanel is on top of the CHART window. I would suggest >drawing the image on a wxPanel yourself since the wxStaticBitmap is >really meant for small images. You can either let the scrolled window >take care of moving the image or get the coords from the scrolled >window and crop the image before drawing. > >Hope this helps, > John Thanks, it appears to work perfectly. :) It's a lot simpler than it was. I still have a few questions though... First, the code, in FULL because the one thing that made my day most difficult is snippets out of context. So much easier if a copy/paste of a working example can be had, then debugging is simple, focus on what change breaks something. For small examples I see no better way than this.. function main() FRAME=wx.wxFrame(wx.NULL,-1,"GPS Plot",wx.wxDefaultPosition,wx.wxSize(1024,768),wx.wxDEFAULT_FRAME_STYLE) FRAME:Centre() FRAME:Show(true) FRAME:CreateStatusBar() BITMAP=wx.wxBitmap("../Charts/Ashton Court.gif",wx.wxBITMAP_TYPE_GIF) local X,Y=BITMAP:GetWidth(),BITMAP:GetHeight() SCROLL=wx.wxScrolledWindow(FRAME,-1) SCROLL:SetScrollbars(1,1,X,Y) CHART=wx.wxPanel(SCROLL,-1,wx.wxPoint(0,0),wx.wxSize(X,Y)) CHART:Connect(wx.wxEVT_LEFT_DOWN,OnLeftDown) CHART:Connect(wx.wxEVT_MOTION,OnMotion) CHART:Connect(wx.wxEVT_PAINT,OnPaint) end --==================== Mouse Handling ====================-- MX,MY,VX,VY=0,0,0,0 function OnLeftDown(event) MX,MY,VX,VY=wx.wxGetMousePosition():GetX(),wx.wxGetMousePosition():GetY(),SCROLL:GetViewStart() end function OnMotion(event) if event:LeftIsDown() then SCROLL:Scroll(VX+MX-wx.wxGetMousePosition():GetX(),VY+MY-wx.wxGetMousePosition():GetY()) end end --==================== Track Drawing =====================-- function OnPaint(event) local DC=wx.wxPaintDC(CHART) DC:DrawBitmap(BITMAP,0,0,false) DC:SetPen(wx.wxPen(wx.wxColour(255,0,0),1,wx.wxSOLID)) DC:DrawLine(0,0,600,600) DC:delete() end --==========================================================-- main() The questions: Why does it need s status bar? It still borks and displays nothing without that being there, and I still can't see why.. Is there a way to make the BITMAP draw once and still work, so I can delete it once it's drawn to the DC for the CHART panel? Is this even in line with the advice on deleting large bitmaps to save resources in MSW? Is it wise to expand the OnPaint() function to assign the wxPen and wxColour to variables on creation so I can delete them individually? I'm not clear as to whether they are orphaned and consuming resources after the DC:delete(). I do suspect that something persists, as after a few tens of loads in a session, the script was failing to draw the chart, only the line. And, why DC:delete() not DC:Delete() like XYZ:Refresh() or ABC:Show()...? :) Small case-sensitive gotchas like this are one thing that really makes it tough to debug stuff for newcomers. If the code is now correct, I want to focus on scaling, so should I do this by converting the loaded bitmap to a wxImage() or would it be faster just to load prescaled bitmaps? If the former, can you give me a minimal template for building the needed conversions into the current code? I can convert to image but I'm not clear at what point the image should be deleted after reconversion to bitmap, or even how to reconvert it. You mentioned cropping. This sounds good if it allows a speed gain by avoiding having to draw the whole of a large image. Will it do that though? I imagine that the dragging of the image will cause this image crop and display to occur with every pixel-shift of motion, and not be fast at all. |
From: John L. <jla...@gm...> - 2009-03-01 09:02:04
|
On Sat, Feb 28, 2009 at 9:34 AM, lostgallifreyan <los...@gm...> wrote: > > Ultimately I want to zoom the view in and out as well as pan it, so if you have clues on how to do that, please let me know. > > > SCRIPT: > > function main() > FRAME=wx.wxFrame(wx.NULL,-1,"GPS Plot",wx.wxDefaultPosition,wx.wxSize(1024,768),wx.wxDEFAULT_FRAME_STYLE) > FRAME:Centre() FRAME:Show(true) > FRAME:CreateStatusBar() > > IMAGE=wx.wxBitmap():ConvertToImage() > IMAGE:LoadFile("Chart.jpg") > local X,Y=IMAGE:GetWidth(),IMAGE:GetHeight() > SCROLL=wx.wxScrolledWindow(FRAME,-1) SCROLL:SetScrollbars(1,1,X,Y) > CHART=wx.wxStaticBitmap(SCROLL,-1,wx.wxBitmap(IMAGE),wx.wxPoint(0,0),wx.wxSize(X,Y)) IMAGE:Destroy() This next wxPanel is on top of the CHART window. I would suggest drawing the image on a wxPanel yourself since the wxStaticBitmap is really meant for small images. You can either let the scrolled window take care of moving the image or get the coords from the scrolled window and crop the image before drawing. Hope this helps, John > LAYER=wx.wxPanel(SCROLL,-1,wx.wxPoint(0,0),wx.wxSize(X,Y)) > BLANK=wx.wxPanel(SCROLL,-1,wx.wxPoint(0,0),wx.wxSize(0,0)) > > CHART:Connect(wx.wxEVT_LEFT_DOWN,OnLeftDown) > CHART:Connect(wx.wxEVT_MOTION,OnMotion) > LAYER:Connect(wx.wxEVT_PAINT,OnPaint) > end > > --==================== Mouse Handling ====================-- > > MX,MY,VX,VY=0,0,0,0 > > function OnLeftDown(event) > MX,MY,VX,VY=wx.wxGetMousePosition():GetX(),wx.wxGetMousePosition():GetY(),SCROLL:GetViewStart() > end > > function OnMotion(event) > if event:LeftIsDown() then > SCROLL:Scroll(VX+MX-wx.wxGetMousePosition():GetX(),VY+MY-wx.wxGetMousePosition():GetY()) > BLANK:Show(nil) BLANK:Show(1) > end > end > > --==================== Track Drawing =====================-- > > function OnPaint(event) > local DC=wx.wxPaintDC(LAYER) > DC:SetPen(wx.wxPen(wx.wxColour(255,0,0),1,wx.wxSOLID)) > DC:DrawLine(0,0,600,600) > DC:delete() > end > > --====================================================================================================================-- > > main() > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > wxlua-users mailing list > wxl...@li... > https://lists.sourceforge.net/lists/listinfo/wxlua-users > |