On Fri, Jun 29, 2012 at 2:34 AM, Paul K <paulclin...@yahoo.com> wrote:
> Hi John,
>
> Thank you for making the binaries available! I gave the Unicode
> binaries a try, but the results are a mixed bag. I can barely get them
> running for my application, which allows me to confirm that UTF-8
> encoding is now working, but other encodings stopped working. For
> example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no
> difference (it looks like it's always "fixed" to utf-8). This may be a
> feature though. If this is going to be the way it is, I'm fine with
> it.

I have never needed to change the wxFONTENCODING so I don't think it
is necessary. I bet you were trying to change it to map upper ASCII
chars appropriately to a font, a poor mans Unicode that probably works
well for Latin languages with tildes and such, but that's about it.
When you use Unicode you don't need to mess with all that since UTF8,
for example, can describe any character.

Note the comment about  "Please note that we will only discuss 8-bit
fonts here and not Unicode (see Unicode Support in wxWidgets)."
http://docs.wxwidgets.org/trunk/overview_fontencoding.html

Unfortunately you either work in Unicode or ANSI and hope that the
upper ASCII chars map to the letters you need. I don't think you can
ever have it both ways as the upper ASCII chars are not
compatible/equivalent to Unicode chars in any format.

> Also, I can't get the binaries to work correctly with my application.
> The first issue is that the existing lua socket binaries fail to load:
>
> ...\bin\lua.EXE: error loading module 'socket.core' from file
> 'bin/clibs/socket\core.dll':
>        The specified module could not be found.
>
> even though the module *is* there and loads fine using the old
> binaries. This may be related to the fact that socket\core.dll seems
> to be compiled against lua5.1.dll, which you didn't include in the
> package (and my existing one didn't work as it's not for 5.1.5).

You can't always expect that a lib compiled with one version of code
to work with another. Ideally you would build wxLua and the socket lib
together to ensure they both are using the same Lua library. In this
case they are trying to use different lua51.dlls which is a real
problem, they have to both use the same one.

I am working on using a proxydll along the lines of this :
http://lua-users.org/wiki/LuaProxyDllFour

It works... but I get missing comctrl32.dll dialogs every once in a
while which makes it very hard to debug what is happening.

wxlua_lua_shared-wx28mswu-2.8.12.dll is lua51.dll, but named so that
there can't be any confusion about what it is or what it belongs to.
In Linux all the wxLua libs are named this way so they won't conflict
with any system libs, you can use symbolic links to "rename" them to
whatever you need them to be called. In Windows, people play fast and
loose with versioning and naming and you get problems like you're
having. For any sort of known stability all libs *must* be compiled
and linked to the same versions of the other libs. Do you know how the
socket binaries were compiled, what flags (/MT vs /MD), what Lua
version, etc? If they match to how wxLua is compiled *and* the Lua
they used is binary compatible, 5.1.4 should be with 5.1.5 it may
work...

> If I comment luasocket out, the app crashed somewhere in
> wxlua_lua_shared-wx28mswu-2.8.12.dll:

No message?

> This is running on Windows Vista (32bit). I only deployed wx.dll and
> wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what
> wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to
> work without 2.8.12.dll). I thought I could pick what version of
> wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that
> way.

wxlua_lua_shared-wx28mswu-2.9.4.dll was an oversight, it is exactly
the same as wxlua_lua_shared-wx28mswu-2.8.12.dll.

> I don't quite understand the difference between lua.exe and
> lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but
> lua_shared.exe runs without that dll also, as you don't seem to
> include the dll.

lua_shared.exe and wx.dll are linked to wxlua_lua_shared-wx28mswu-2.8.12.dll.

lua.exe is a standalone executable.

> Also,  wxLua* binaries (Freeze, Edit, etc.) seem to be statically
> compiled and the previous version had them dynamically compiled (which
> would be my preference, although other people may prefer it
> differently).

I think static is the way to go and using the proxydll above should
solve the lua51.dll problem (at least name problem) for people trying
to use random precompiled libs with require().

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

The bottom line is that the next release will be quite different, much
simpler for deployment, and far more compatible when using other libs.

Regards,
     John

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users

Reply via email to