[fixed]copy past bug with edit boxes

[Akabane87]

Hi there,

I just noticed a really annoying bug with the copy past from outside to an edit box (verified with my own app + any example using the GUI). If your string copied from outside contains some accentuated letters (like é, è, à...), thoses letters are replaced by blanc space in the edit box. For example you can write in the edit box any string with accentuated letters from your keyboard : all willbe displayed correctly. Then copy what you wrote and past it again, and accentuated letters just wiped...

I reproduced this bug with the 1.8 version of irrlicht.

Any hot fix I could apply without modifying the sources of the lib for my project ? (It's quite a mess for my editor's users that can't use the copy past function and make them loose a lot of time).

Regards,

[CuteAlien]

On which OS? I know Linux copy & paste is broken - just couldn't figure out how it has to work in X11 correctly so far (as so often the only example given doesn't work). Don't know about problems on other systems yet but sounds like it doesn't handle unicode characters on first view.

[Akabane87]

oops sorry it's on windows seven.

[CuteAlien]

I fixed it in the svn 1.8 release branch and in svn trunk. But you need to rebuild Irrlicht or wait until the next nightly build has been produced. Will work now on Windows - still failing on Linux/X11 (but failed there before as well, so no big difference - have to figure out X11 another time as this is never trivial).

[Akabane87]

Ok, I'll give a look to the fix and try to find a way to fix it on the fly without recompiling the dll. Thanks.

[CuteAlien]

You shouldn't be too worried about re-compiling Irrlicht. You have already done the hard part of setting up directx and windows sdk or you couldn't compile your own application. So the hardest part left is probably installing an svn-client (use tortoise-svn on Windows) and downloading Irrlicht svn. Then you can just open the project file and click on compile. Being able to work directly with the source is the biggest feature open-source libraries have - you miss out if don't use that :-)

[Akabane87]

lol no, the reason is just that I fixed a lot of issues already, sometimes the hard way, to not modify the engine (at the beginning because I wanted to be able to change irrlicht version without having to port my changes on it). But you make a point : this one will be normally fixed in all future branches, so I suppose I can recompile the engine for this (+ I don't have to care about the linux version cause it won't work anyway lol).

ps : I already use git through ssh (private key setup on windows made me mad x_x) for my project

[CuteAlien]

Ah yes - I get that. Most stuff I'm currently working at is getting rid of the need of having to use patches for Irrlicht myself ;-)

[Akabane87]

Bit off topic but the worst one is probably this one (to gain access to the scissor for my own specific render functions) :

Not proud of this but it was this or modify the sources...

Code: Select all

 
#ifdef _IRR_WINDOWS_
    IDirect3DDevice9* D3DDevice = NULL;
#endif
    if (clip)
    {
        if (clip->isValid())
        {
            if(driver->getDriverType() == video::EDT_OPENGL)
            {
                glEnable(GL_SCISSOR_TEST);
                const core::dimension2d<u32>& renderTargetSize = driver->getCurrentRenderTargetSize();
                glScissor(clip->UpperLeftCorner.X, renderTargetSize.Height-clip->LowerRightCorner.Y,
                    clip->getWidth(), clip->getHeight());
            }
#ifdef _IRR_WINDOWS_
            else if(driver->getDriverType() == video::EDT_DIRECT3D9)
            {
                // MONSTRUOUS HACK TO GET THE D3D DEVICE
                // in irr 1.8 in 32 bits : D3D device is at offset 0x000005fc
                D3DDevice = (IDirect3DDevice9*)(*((size_t*)((size_t)driver+0x000005fc)));
 
                if(D3DDevice)
                {
                    D3DDevice->SetRenderState(D3DRS_SCISSORTESTENABLE, TRUE);
                    RECT scissor;
                    scissor.left = clip->UpperLeftCorner.X;
                    scissor.top = clip->UpperLeftCorner.Y;
                    scissor.right = clip->LowerRightCorner.X;
                    scissor.bottom = clip->LowerRightCorner.Y;
                    D3DDevice->SetScissorRect(&scissor);
                }
            }
#endif
        }
    }
 

[hendu]

On many hw stencil is faster than scissor (and more versatile, how about a rose-shaped cutout instead of rect ), but since rtt stencil is not enabled in upstream irr either, well...

[CuteAlien]

Pretty evil, especially as you can actually access IDirect3DDevice9 by the interface with IVideoDriver::getExposedVideoData().D3D9.D3DDev9 ;-)

[zerochen]

hi,

instead of:

Code: Select all

                // MONSTRUOUS HACK TO GET THE D3D DEVICE
                // in irr 1.8 in 32 bits : D3D device is at offset 0x000005fc
                D3DDevice = (IDirect3DDevice9*)(*((size_t*)((size_t)driver+0x000005fc)));
 

why not using this:

Code: Select all

D3DDevice = driver->getExposedVideoData().D3D9.D3DDev9

?

regards
zerochen

[Akabane87]

lol never found it in the doc x_x. Had seen the getExposedVideoData() function but I was not aware we were able to access all specific drivers through it and the real device behind. Thanks for the info .