wxlua-users Mailing List for wxLua

On Fri, Mar 27, 2009 at 9:03 AM, Andre Arpin <ar...@ki...> wrote:
> John Labenski <jlabenski@...> writes:
>
> the current version is codes as
>    unsigned int mask = (int)wxlua_getnumbertype(L, 3);
> should be
>    unsigned int mask = wxlua_getnumbertype(L, 3);
>
> the cast overrides the definition

Yep, I forgot to commit the proper changed files. I had a problem
where my CVS was out of sync with sourceforge's for some reason. Now
it should really be fixed.

    unsigned int mask = (unsigned int)wxlua_getuintegertype(L, 3);

where "unsigned long wxlua_getuintegertype()" does this (pretty much at least)

double value = lua_tonumber(L, stack_idx);
unsigned long ulong_value = (unsigned long)value;

It's a multistep process to not let the compiler optimize away the
double->ulong->int conversion and have the same problem we started off
with.

Hope it works now,
    John

On Mon, Mar 30, 2009 at 1:05 AM, Eero Pajarre <epa...@gm...> wrote:
> I am trying to use the wxBitmapComboBox but it seems to
> crash on me while I either try to set or get its selection using
> SetStringSelection or GetStringSelection.
>
...
> with the test shown above the crash possibly happens in
> wxLua_wxControlWithItems_SetStringSelection .
>
> When doing GetStringSelection the crash happens somewhere
> 0xdddddddd
> t_console!wxItemContainerImmutable::GetStringSelection+0x4b
> t_console!wxLua_wxControlWithItems_GetStringSelection+0x4e
>
> I get the feeling that something is broken in the class inheritance
> either in wxLua or wxWidgets side...

It's unfortunately on the wxLua side. I might have inadvertently put
wxControlWithItems as it's base class, but it should actually be a
couple different ones. I am going to change the bindings so that
classes can have multiple base classes to make it possible to wraps
these more easily. It'll probably take a few days since it's a pretty
big fix.

Regards,
   John

I am trying to use the wxBitmapComboBox but it seems to
crash on me while I either try to set or get its selection using
SetStringSelection or GetStringSelection.

example: add the following line to samples/controls.wx.lua
(line 514)

-- -----------------------------------------------------------------------

    control = wx.wxBitmapComboBox(scrollWin, ID_BITMAPCOMBOBOX,
"wxBitmapComboBox",
                                         wx.wxDefaultPosition, wx.wxDefaultSize,
                                         {"Item 1", "Item 2", "Item 3
text is long to check default size"},
                                         wx.wxTE_PROCESS_ENTER) --
generates event when enter is pressed
    control:Append("Appended w/ bitmap", bmp)
    control:Insert("Inserted at 0 w/ bitmap", bmp, 0)
    control:SetItemBitmap(2, bmp)
    control:SetStringSelection("Item 1"); // #####ADD THIS LINE####
    AddControl("wxBitmapComboBox", control)

    -- -------------------------------------------------------------------

I seem to get the crash both on Windows XP and linux. Windows with
somewhat aged CVS version, and Linux with up to date CVS.

with the test shown above the crash possibly happens in
wxLua_wxControlWithItems_SetStringSelection .

When doing GetStringSelection the crash happens somewhere
0xdddddddd
t_console!wxItemContainerImmutable::GetStringSelection+0x4b
t_console!wxLua_wxControlWithItems_GetStringSelection+0x4e

I get the feeling that something is broken in the class inheritance
either in wxLua or wxWidgets side...


          Eero

John Labenski <jlabenski@...> writes:

> 
> Hi Andre,
> 
> I have finally committed a robust fix for this. I haven't tested it w/
> VC6, but it should work.
> 
> Regards,
>     John
> 

the current version is codes as
    unsigned int mask = (int)wxlua_getnumbertype(L, 3);
should be
    unsigned int mask = wxlua_getnumbertype(L, 3);

the cast overrides the definition
Andre

PS: Thanks for all the fix up

John Labenski <jlabenski@...> writes:

> 
> I'm sorry, this is not something that I have time or interest in. I
> recommend that if you are serious about this that you look at the
> wxWidgets wiki about building wxWidgets, then move to building wxLua,
> and finally wxMidi. Once you have those three built you can write a
> binding file for wxMidi, like the ones the wxLua's binding directory,
> and generate the C/C++ code to be compiled into a library to build
> into wxLua. Yes, it will be a fair amount of work.

Well, now you put it like that it sounds like a rediculous solution.
If everyone who needed to drive had to build big chunks of the car,
no-one would go anywhere! If it's too much for the person best placed
to do it, then it's obviously too much for anyone else.

Besides, that degree of work is absurd if it's possible to use a small
program on a RAM drive to read a file, saved to same RAM drive, to get
the data out. The program I found comes very close to this. I'll ask
the maker, if I can find him, if he's willing to make a copy that has
no GUI, takes specs from INI file, perhaps. With a separate executable,
there's no need to worry about keeping up with CVS and all that.
This really ought to be doable without having to devote a chunk of
life to reinventing a wheel. I thought that wxMIDI was supposed to
BE that wheel anyway, yet you make it sound like I'd be better off
designing from scratch. It seems that it might be so, learning enough
C to write a tiny app to read from saved file and port to and from MIDI,
forget about trying to integrate closely with a system whose writer(s)
really don't want to know.

You speak of MIDI as if I mentioned music piracy or something. It really
seems to put your back up somehow, abnd I really don't know why.

I'm sorry, this is not something that I have time or interest in. I
recommend that if you are serious about this that you look at the
wxWidgets wiki about building wxWidgets, then move to building wxLua,
and finally wxMidi. Once you have those three built you can write a
binding file for wxMidi, like the ones the wxLua's binding directory,
and generate the C/C++ code to be compiled into a library to build
into wxLua. Yes, it will be a fair amount of work.

Good luck,
    John

On Tue, Mar 24, 2009 at 1:15 PM, lostgallifreyan
<los...@gm...> wrote:
>> http://wxcode.sourceforge.net/showcomp.php?name=wxMidi
>
> Hi John, any followup to this one? I Googled further since posting,
> and found an archive of another mailing list, I see you've encountered
> it before. :) I don't know if the encounter was favourable or not though.
> What chance of making it work for me? I really want this one, and I don't
> know how or if it can be adapted to wxLua, but if it works it will make
> me very happy. I'll be publishing the whole DX7-Edit soon anyway (and
> would like to know if it's best done here, or on SourceForge, perhaps),
> but I currently have to use a standalone tool to read a file then send,
> and this is clumsy. I have some nice plans for MIDI and wxLua, specifically
> a way to remap messages in realtime, as no tool does this how I want, it's
> a very unexploited niche in programming, despite the existing tools attempting
> to do it.
>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

> http://wxcode.sourceforge.net/showcomp.php?name=wxMidi

Hi John, any followup to this one? I Googled further since posting,
and found an archive of another mailing list, I see you've encountered
it before. :) I don't know if the encounter was favourable or not though.
What chance of making it work for me? I really want this one, and I don't
know how or if it can be adapted to wxLua, but if it works it will make
me very happy. I'll be publishing the whole DX7-Edit soon anyway (and
would like to know if it's best done here, or on SourceForge, perhaps),
but I currently have to use a standalone tool to read a file then send,
and this is clumsy. I have some nice plans for MIDI and wxLua, specifically
a way to remap messages in realtime, as no tool does this how I want, it's
a very unexploited niche in programming, despite the existing tools attempting
to do it.

>> One problem is in the toolbar buttons that used to show system colours,
>> so black on grey controls would show orange on black in my system.
>> (Works for me, especially given that another black, for statictext,
>> shows as white on black, so I get more immediate info from the display...)
>> In the new wxLua, the bitmaps are rendered exactly as I made them. A look
>> at the documentation suggests this maybe should not be so, and it certainly
>> worked ok in wxLua v2.54.

>I'm not sure I understand, the bitmaps are rendered exactly as you
>would see them in a image viewer? This is good, right?

Yes, if it's to be shown as such. :) But in MSW, a button with black on grey
(C0C0C0) is considered as using system colours. In my scheme those would
change to match the rest of the system, as happened with wxLua v2.54. If
the same bitmap were rendered as a static bitmap, then the colours would
be literal. I can always specify exact colours, but then they might look
wrong on a control in a standard scheme, or on another platform.

I'm not sure how Windows decides these things, but I guess it either breaks
if a nonstandard palette is used, or it detects the right 16 colour type.
For example, 16 colour icons can take any colour in the palette so long as
the black, white, and the transparent and inverse transparent colours are
as intended. Very odd stuff results if that's not done right.

Colour rules like those are very often broken. A vast number of web designers
and program designers specify foregrounds and not backgrounds at same time,
resulting in illegible dialogs and so forth. I have found this to be a good
guide to the rigour of coding, at times. wxLua has it well, apart from the
button bitmaps. They used to work, so they could work again. I mentioned
CreateTools() only because I wondered if that might have been used to make
it work, though it wasn't part of my original DX7-Edit code either.

John Labenski <jlabenski@...> writes:

> If you don't care what ID a control is given you can use -1to have a
> unique number set for you. However if you want to get back at the
> control or be able to figure out which control an event came from you
> should set a variable to some unique number, use it in the widget's
> constructor, and then reference it as necessary.
> 

Ok, that sounds like how I thought of it so I'll do that, though isn't it
ok to do event:GetId() to get it once it's been assigned -1 to let wxLua
decide? That's how I did it in DX7-Edit, and that still works in the newly
adapted copy. After all, I don't need to know it unless something happens. :)
I only need it if I have to set the control's value as user feedback.
I guess if I want to save time in a fast loop I can set (or get) get its
ID before hand and look up a variable, but I suspect there's not much
speed difference.

Hi Andre,

I have finally committed a robust fix for this. I haven't tested it w/
VC6, but it should work.

Regards,
    John

On Wed, Feb 25, 2009 at 4:51 PM, Andre Arpin <ar...@ki...> wrote:
>>
>>     int mask = (int)wxlua_getnumbertype(L, 3);
>>
>
> sorry
>
>    int mask = (int)wxlua_getnumbertype(L, 3);
>
> does not work
>
>    int mask = (unsigned)wxlua_getnumbertype(L, 3);
>
> does
>
> Andre
>
>
> ------------------------------------------------------------------------------
> 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
>

On Sat, Mar 21, 2009 at 3:02 PM, lostgallifreyan
<los...@gm...> wrote:
> DX7-Edit is now showing a GUI, and most errors are small and localised, just some remaining incompatible function calls, mostly.
>
> One problem is in the toolbar buttons that used to show system colours, so black on grey controls would show orange on black in my system. (Works for me, especially given that another black, for statictext, shows as white on black, so I get more immediate info from the display...) In the new wxLua, the bitmaps are rendered exactly as I made them. A look at the documentation suggests this maybe should not be so, and it certainly worked ok in wxLua v2.54.

I'm not sure I understand, the bitmaps are rendered exactly as you
would see them in a image viewer? This is good, right?

> >From the "wx.chm" file for wxWidgets 2.8.7, page called Toolbar overview:
> "wxToolBar95. Uses the native Windows 95 toolbar class. It dynamically adjusts its background and button colours according to user colour settings. CreateTools must be called after the tools have been added."
>
> According to their decriptions, none of the Window Styles have a bearing on this. I tried adding a TBAR:CreateTools() as directed above, right after adding tools and separators and just before TBAR:Realise(), and wxLua reported an error (unknown method CreateTools on a wxToolBar type), so that isn't going to make their system colours display right. Any idea what might?
>

wxToolBar::CreateTools() does not exist (anymore). Unfortunately the
2.8 docs haven't been updated yet.

Regards,
    John

On Sat, Mar 21, 2009 at 12:56 PM, lostgallifreyan
<los...@gm...> wrote:
> I'm updating DX7-Edit, using the error reporting in the new wxLua as a guide, fixing each error as I meet it.
>
> I notice that the ID_TOOLBAR is nil, and this is I think why an error is reported when I use it. I checked online, and see that it has a value of 1040 according to a long page I found. If I insert 1040 directly, it passes and moves to the next error. I checked with the older wxLua (v2.54) to see what value it had at the point of calling, and it was also nil!

I think this constant was removed in newer versions of wxWidgets and
therefore removed in wxLua.

> So three questions:
> How do I make wxLua assign these ID_XYZABC values so they aren't nil?

Just create a variable ID_XYZABC = 12

> Would setting a value of -1 make it chose the right default value of 1040. (I notice that -1 is often used to indicate that the system uses a default, not explicit value of -1).

If you don't care what ID a control is given you can use -1to have a
unique number set for you. However if you want to get back at the
control or be able to figure out which control an event came from you
should set a variable to some unique number, use it in the widget's
constructor, and then reference it as necessary.

> How did wxLua manage ok with them set to nil in v2.54?

Previously nil == 0 which now throws an error.

Regards,
    John

Attila <ejjeliorjarat@...> writes:

> 
> Hi!
> The easiest way is to use Lua's os.getenv() function,
> for example local path = os.getenv("PATH") or what you need.
> Regards: Attila
> 

Thanks. True. I like to use inbuilt Lua functions if they're there.
I'd forgotten about this one till after I first posted.

(I'm sending this reply via Gmane's web site again, still not seeing
incoming mails from the list. I notice it can take a reply and thread
it ok though, I reused an earlier thread-starting post, forgetting to
change the subject line, so I guess I can copy the line from Gmane's
page and use that, it should at least partly get a reply in the right
place in the right thread. Not much I can do if that depends on headers
I don't get to see though).

DX7-Edit is now showing a GUI, and most errors are small and localised, just some remaining incompatible function calls, mostly.

One problem is in the toolbar buttons that used to show system colours, so black on grey controls would show orange on black in my system. (Works for me, especially given that another black, for statictext, shows as white on black, so I get more immediate info from the display...) In the new wxLua, the bitmaps are rendered exactly as I made them. A look at the documentation suggests this maybe should not be so, and it certainly worked ok in wxLua v2.54.

>From the "wx.chm" file for wxWidgets 2.8.7, page called Toolbar overview:
"wxToolBar95. Uses the native Windows 95 toolbar class. It dynamically adjusts its background and button colours according to user colour settings. CreateTools must be called after the tools have been added."

According to their decriptions, none of the Window Styles have a bearing on this. I tried adding a TBAR:CreateTools() as directed above, right after adding tools and separators and just before TBAR:Realise(), and wxLua reported an error (unknown method CreateTools on a wxToolBar type), so that isn't going to make their system colours display right. Any idea what might?

lostgallifreyan <lostgallifreyan@...> writes:

> Is there a way to get OS environment variables, other than to redirect the ou
> tput of command SET to file, then parse the file to get them? And if so, is t
> here a way that is as widely compatible with other platforms as wxLua is?
> 


Never mind, there is in Lua itself: os.getenv("VAR")

I'm updating DX7-Edit, using the error reporting in the new wxLua as a guide, fixing each error as I meet it.

I notice that the ID_TOOLBAR is nil, and this is I think why an error is reported when I use it. I checked online, and see that it has a value of 1040 according to a long page I found. If I insert 1040 directly, it passes and moves to the next error. I checked with the older wxLua (v2.54) to see what value it had at the point of calling, and it was also nil!

So three questions:
How do I make wxLua assign these ID_XYZABC values so they aren't nil?
Would setting a value of -1 make it chose the right default value of 1040. (I notice that -1 is often used to indicate that the system uses a default, not explicit value of -1).
How did wxLua manage ok with them set to nil in v2.54?

Hi!
The easiest way is to use Lua's os.getenv() function, for example local path = os.getenv("PATH") or what you need.
Regards: Attila

http://wxcode.sourceforge.net/showcomp.php?name=wxMidi

Can anyone tell me how I can make this work with wxLua in Windows? It appears complete and well documented, but I've never linked a library to anything before. As far as I can tell, the binaries included in the package (extension LIB) might be usable directly with wxLua, but I don't know if so, or how. If someone who does can have a look at them, and tell me how, please do.

I have built, a couple of years ago or more, a DX7 editor. (Yamaha's DX7 is a very popular and famous electronic sound synthesizer). This editor is a very finished and complete example of wxLua, though yet to be adapted for the latest wxLua builds, with one major weakness: it needs someone else's executable to read a saved file to output MIDI data to a hardware port. This is far from ideal, MIDI needs speed and, this makeshift method is slow and untidy. I can return the effort made on my behalf, as this editor will help bring favourable attention to wxLua. Further, with MIDI support in wxLua, a lot more people will become involved in wxLua because MIDI has a strong following of technically minded enthusiasts keen to build their own gear.

John, (Labenski), I remember you saying in an email that you weren't interested in MIDI, but if that wxMIDI has done most of the work already, this is worth a second look. I'll be much happier about contributing to wxLua with actual code if the stuff I really want to do most can work on it. MIDI is a machine control language with strong hardware and software support. If you help make this possible, you won't regret it. Once you see what it can do, I think you'll become interested anyway.

John, I answered my own post with a mention of os.getenv() but thanks those wxLua functions will be useful if I want to change any.

I don't think my answering post showed up. I can't see it on Gmane, which is where I answered the first one. I did that because the list isn't forwarding copies of my posts or replies to them, as I set it to do. I got sporadic sends from it last time there was any activity here, but not each time, and not now. The only way I can answer any post is to make a new one, from my email client, and the only way I can see new posts is a web interface. If anything else breaks I won't be able to use it at all.

I think the list must know the address to send things to, or it would not recognise posts coming from that address, and if you can see this, it must have that right.
I just checked the list settings I made last time to see if they stuck, and they did, so I should be seeing copies and new mails. I saw your reply on Gmane the moment I went there to see if my reply to my own post showed up, so it doesn't look like a delay problem.

On Fri, Mar 20, 2009 at 6:21 PM, lostgallifreyan
<los...@gm...> wrote:
> Is there a way to get OS environment variables, other than to redirect the output of command SET to file, then parse the file to get them? And if so, is there a way that is as widely compatible with other platforms as wxLua is?
>

Use these functions:

http://docs.wxwidgets.org/stable/wx_environfunctions.html#environfunctions

wxGetenv()
wxGetEnv()
wxSetEnv()
wxUnsetEnv()

Regards,
    John

Is there a way to get OS environment variables, other than to redirect the output of command SET to file, then parse the file to get them? And if so, is there a way that is as widely compatible with other platforms as wxLua is?

John Labenski <jla...@gm...> wrote:
(06/03/2009 03:06)

>You can also try using
>wxDC::SetUserScale() IIRC.

Further to that last message, I'd been trying it in the OnPaint() handler because when I tried it in the Main() function where the bitmap is loaded, it didn't do anything (though wxLua didn't protest at my usage). I tried again, with mixed results.

  local DC,C,P=wx.wxMemoryDC()
  DC:SelectObject(BITMAP)
  local X,Y,x,y=string.find(T[1],"^(.-)\t(.-)$")
  for N in ipairs(T) do
    C=wx.wxColour(255,0,0)  P=wx.wxPen(C,1,wx.wxSOLID)  C:delete()  DC:SetPen(P)  P:delete()
    _,_,X,Y=string.find(T[N],"^(.-)\t(.-)$")  DC:DrawLine(x+0,y+0,X+0,Y+0)  x,y=X,Y
  end
  DC:SetUserScale(0.5,0.5)
  DC:SelectObject(wx.wxNullBitmap)
  DC:delete()

At the location right before delete, it does nothing. If I place it before the track drawing to wxMemoryDC it scales the track nicely. But at no point will it scale the bitmap. I was thinking that bitmap was loaded to the MemoryDC and was being drawn on directly by that track, but it can't be if one scales but not the other. Now I don't know exactly what I have...

John Labenski <jla...@gm...> wrote:
(06/03/2009 03:06)

>
>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.

I still don't understand.. Unless you mean keeping them there, by assigning them to variables as I mentioned before deleting a DC. ('Saving' to most people, means to disk).

>You can also try using
>wxDC::SetUserScale() IIRC.

Nice, but it looked vile at half-scale. :) And moved like crystallised molasses, and wouldn't show at all at 2x. I think I'll crop and do bicubic upscale on small areas, and a bilinear shrink for a 'view all' option. That way I can avoid scrolling and scaling at same time. Unlike the tools used on PDA's, I have 1280x1024 pixels to play with.

John Labenski <jla...@gm...> wrote:
(06/03/2009 03:13)

>On Wed, Mar 4, 2009 at 3:15 AM, lostgallifreyan
><los...@gm...> wrote:
>>
>> 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.
>>
>
>It might be because you're using Win98. wxWidgets 2.8 is really geared
>towards Win XP which is already about seven years old. I would suggest
>moving to Win 2000, if possible, since my experience is that it runs
>at least as fast as Win98 and doesn't crash. Just a suggestion...

Not moving. But your suggestion of W2K is a good one. :) I liked that OS better than WXP, the few times I tried it, and I'll look at it again. But I depend on W98 for hardware and some software, and the raw DOS underpinning too. Too many reasons to stay. But those are MY reasons, so here is a reason that might be far more useful to you and others:

http://www.msfn.org/board/index.php?showtopic=128308

Several posts there say something I've long been aware of, but far better than I usually say it, and some of them are serious coders whose views carry some weight, (especially Rudolph Loew who has posted elsewhere on that forum, who is firmly staying with W98 and who sells patches for various aspects of it, one of which I use to get 48 bit LBA addressing for large hard disks).

The problem is not so much the OS, but the program, and that later OS's allow lazier coding because they hide flaws better. While I learn wxLua, I think it gives me yet another excellent reason to stay with W98. If my code works on on this, the chances are that it will work right elsewhere, leaving only specific details of other OS's to attend to as noted in the docs I've seen. That wxLua and wxWidgets persist in supporting W9X is a Good Thing. I'm very pleased about that.

The drag-drop problem might easily be fixed by limiting dropped files to 10 or 50, and where precise location on a GUI is important, I guess it makes sense to enable dropping on a single widget rather than the whole frame and getting co-ordinates. There can be several ways to work round this. Getting mouse position onLeftUp, for example..


PS. I'll be getting 1 GB of RAM to use instead of 512 MB. Amongst changes needed to make that work well, I've read that the [vcache] settings in System.ini include namecache and directorycache values. That first one might directly help the drop-files problem, if it does I'll post again. I won't know for a while because testing vcache settings isn't a thing that can be evaluated fast.

On Wed, Mar 4, 2009 at 3:15 AM, 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.
>
> 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.
>

It might be because you're using Win98. wxWidgets 2.8 is really geared
towards Win XP which is already about seven years old. I would suggest
moving to Win 2000, if possible, since my experience is that it runs
at least as fast as Win98 and doesn't crash. Just a suggestion...

Regards,
     John