customtreectrl, is it possible to decrease the drag delay ?

hello,

I've been playing around with customtreectrl for a week,
and noticed that dragging nodes,
resulted in about 30% no drag,
because I'm too fast ?
Is it simply possible to decrease the drag delay ?

thanks,
Stef Mientki

thanks Andrea,
at the moment I don't have the problem application available, I'll check this evening.
cheers,
Stef

Andrea Gavana wrote:

Hi Stef,

I've been playing around with customtreectrl for a week,
and noticed that dragging nodes,
resulted in about 30% no drag,
because I'm too fast ?
    
I have played a bit with the demo and, no matter how fast I run my
mouse, I always see the begin drag/end drag events fired. Moreover,
there is a physical limit to the speed the user can drag and drop an
item, as you have to be careful on *where* you want to drop your
dragged item.

Is it simply possible to decrease the drag delay ?
    
There is no drag delay in CustomTreeCtrl other than the one given by
the platform (if it exists). CustomTreeCtrl checks if the user is
dragging (using event.Dragging()), with this code:

        if event.Dragging() and not self._isDragging and ((flags &
TREE_HITTEST_ONITEMICON) or (flags & TREE_HITTEST_ONITEMLABEL)):

            if self._dragCount == 0:
                self._dragStart = pt

            self._countDrag = 0
            self._dragCount = self._dragCount + 1

            if self._dragCount != 3:
                # wait until user drags a bit further...
                return

            command = (event.RightIsDown() and
[wxEVT_TREE_BEGIN_RDRAG] or [wxEVT_TREE_BEGIN_DRAG])[0]

So, it just wait that dragCount is equal to 3, to be sure that the
dragging event isn't a spurious action. You might try decreasing the
value to 2, but I don't think it will change that much.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629.
The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629.

···

On Nov 22, 2007 11:51 PM, Stef Mientki wrote:

Hello,
I'm developing an application on Windows that will be used by blind
users together with a screenreader, a software that can read what's
on video. The screenreader need to be configured and customized to
work well and to do this I must deliver my application with a
configuration file. The configuration file should be named after the
name of the process module associated with the main window of the
program. I cannot access the code for the screenreader but I'm almost
sure that, for getting the name of the configuration file, it call
something like:

GetModuleFileNameEx(dwProcessID, (HINSTANCE)GetWindowLong(hWnd,
GWL_HINSTANCE), szFilename))

with hwnd as the main window.
  (I also used WinExplorer, a free tool with source code, that shows
a lot of parameters about a process and its windows)

With a wxPython application this name is always __core__.pyd so my
application should be associated with a configuration file with
__core__ as name. The problem arise if there are more than one
application written with wxPython. The configuration file is unique
and stored in a private directory of the screenreader! So there
cannot be two files with the same name.

This is unfortunate. However, detecting a specific application is a
pretty hard problem so I'll give them something of a pass for doing it
badly.

I also went through the wxPython source code to search where the
hinstance for a class is set but I cannot understand it very well,
perhaps I need to study it in depth. I only found
src\msw\app.cpp(354): wndclass.hInstance = wxhInstance;
but I don't understand how to change this and its effects.

You can't just change the hinstance. It's what ties a window with a
specific running process.

But my question is: there's a way to change the module name? Probably
changing the histance associated to the main window could be a
solution, but how to do it in Python? Or other ideas?

If you package your application with py2exe, it's quite possible that
you'd get the name of your packaged executable. In fact, I'm quite
surprised that whatever it's doing resolves to the wxPython .pyd and
not to python.exe. Have you confirmed that a config file for
python.exe isn't picked up?

···

On Nov 23, 2007 10:28 AM, Enrico Bortolazzi <enrico.bortolazzi@infinito.it> wrote:

Thank you very much,
Enrico

You can't just change the hinstance. It's what ties a window with a
specific running process.

Yeah, this was what I knew, and you confirm! I also don't like to do something very dirty, it opens the door to future problems.

> But my question is: there's a way to change the module name? Probably
> changing the histance associated to the main window could be a
> solution, but how to do it in Python? Or other ideas?
>

If you package your application with py2exe, it's quite possible that
you'd get the name of your packaged executable. In fact, I'm quite
surprised that whatever it's doing resolves to the wxPython .pyd and
not to python.exe. Have you confirmed that a config file for
python.exe isn't picked up?

To discover which config file is picked up is quite easy, inside my application I type a specific key combination and the screenreader try to open a _core_ file (in case it doesn't find it you get an empty file ready to be written).
I used also py2exe but nothing changed. The package executable name is associated with the main process (the same as for python.exe if run form the py) but the main window is 'associated' to _core_.py. If you download WinExplorer you can see it. It took me a long time to understand where was the problem, but now I have no solution :slight_smile:
I wrote to the screenreader producer but at the moment I got no answer.

Anyway, many thanks for your attention,
Enrico

···

At 10.50 23/11/2007 -0600, Chris Mellon wrote: