RE: [perl-win32-gui-users] Internal Dragging
Has anyone implemented TreeViews or Listboxes with internal dragging, i.e., to move nodes/items within the control? The mouse events are (or at least should be) trivial, but the drag image is another matter. A simple line indicating the new position of the item/node would be sufficient. There is an example of Listbox dragdrop in the samples folder, and if you search this list you should find an example of a treeview dragdrop. Cheers, jez.
Re: [perl-win32-gui-users] Internal Dragging
On Thu, 01 Jun 2006 02:08:04 -0600, Jeremy White <[EMAIL PROTECTED]> wrote: There is an example of Listbox dragdrop in the samples folder, and if you search this list you should find an example of a treeview dragdrop. The messages in the list, at least searching under 'treeview' and 'drag', don't seem to indicate that anyone has actually successfully made this work under 5.8, only that it's theoretically possible. (If I had found good info in the list archives, I would not have posted a new message to the list.) I should have looked in the samples (the file is even called 'listview_drag_drop.pl') but I am used to them being no good for advanced topics.
Re: [perl-win32-gui-users] Win32::GUI::Scintilla
On Thu, 01 Jun 2006 00:03:21 -0600, Octavian Rasnita <[EMAIL PROTECTED]> wrote: I sent Octavian the Win32::GUI::Scintilla 1.8 PPM I made, but he got the following error. I've only ever built for myself before, not for dsitribution. Can someone tell me how to build so any version of the C runtime (MSVCRxx.dll) can be used? Thank you. I have installed Win32::GUI::Scintilla, but when trying perl -MWin32::GUI::Scintilla -e1 it appears the following error window: perl.exe - Unable To Locate DLL The dynamic link library MSVCR71.dll could not be found in the specified path D:\usr\site\lib\auto\Win32\GUI\Scintilla;.;C:\WINNT\system32;C:\WINNT\system ;C:\WINNT;D:\pdk\bin\;D:\usr\bin\;d :\Apache2\bin\;d:\Apache2\modules\;d:\mysql\bin\;C:\WINNT\system32;C:\WINNT; C:\WINNT\System32\Wbem;C:\P rogram Files\SecureCRT 3.0;C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual Studio\Common\Tools;C:\Program Files\Microsoft Visual Studio\VC98\bin. OK
Re: [perl-win32-gui-users] Internal Dragging
Sean Healy wrote: On Thu, 01 Jun 2006 02:08:04 -0600, Jeremy White <[EMAIL PROTECTED]> wrote: There is an example of Listbox dragdrop in the samples folder, and if you search this list you should find an example of a treeview dragdrop. The messages in the list, at least searching under 'treeview' and 'drag', don't seem to indicate that anyone has actually successfully made this work under 5.8, only that it's theoretically possible. (If I had found good info in the list archives, I would not have posted a new message to the list.) I should have looked in the samples (the file is even called 'listview_drag_drop.pl') but I am used to them being no good for advanced topics. I know for a fact that there is an example of treeview dragndrop on the list. I posted it. It's in there somewhere, with complete working code. Jason P.
Re: [perl-win32-gui-users] Internal Dragging
Sean Healy wrote: On Thu, 01 Jun 2006 06:43:57 -0600, Jason P <[EMAIL PROTECTED]> wrote: I know for a fact that there is an example of treeview dragndrop on the list. I posted it. It's in there somewhere, with complete working code. I use Opera for my email. It preserves searches in a side panel, and continually updates them. Your post, in fact, showed right up in my search as soon as I got it. So I rechecked my search results for things you posted, and sure enough, there it was, but it showed up as a quoted reply. Opera shows these in another color, and I tend to ignore them when scanning emails, so I don't end up reading the same lines over and over again as they've propagated through threads. But it is there, so thank you; it'll help a lot. You're welcome. And watch out for that GDI draw glitch.
[perl-win32-gui-users] BrowseForFolder & Make New Folder
I've been trying to get the "Make New Folder" button to appear in the BrowseForFolder dialog. I think that BIF_NEWDIALOGSTYLE (0x0040?) needs to be set. Tried that with no such luck. According to Microsoft's info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/structures/browseinfo.asp OLEInitialize or CoInitialize must be done before calling the dialog. I tried this with no luck. My Code: Win32::OLE->Initialize(Win32::OLE::COINIT_OLEINITIALIZE); my $dir=$mw->BrowseForFolder(-root=>0x0040); Can anyone give me the correct couple of lines of code to make this work? Many thanks Eric
Re: [win32-gui] Re: [perl-win32-gui-users] Win32::GUI::Scintilla
Sean Healy wrote: On Thu, 01 Jun 2006 00:03:21 -0600, Octavian Rasnita <[EMAIL PROTECTED]> wrote: I sent Octavian the Win32::GUI::Scintilla 1.8 PPM I made, but he got the following error. I've only ever built for myself before, not for dsitribution. Can someone tell me how to build so any version of the C runtime (MSVCRxx.dll) can be used? >> The dynamic link library MSVCR71.dll could not be found in >> the specified path. Not possible AFAIK, you have to build for a specific runtime. I believe that the licence for MS VC++ allows you to distribute msvcr71.dll (but you should check). I'd be surprised if Octavian doesn't have a copy on his machine somewhere anyway ... he just need to make a copy and put it somewhere on this path (or in the same directory as perl.exe?) so that the running executable can find it when it wants it. An alternative is to build for msvcrt.dll (which IIRC is distributed with all versions of windows.) To do this you need a copy of the msvcrt.lib that is distributed with VC6, and make you compile environment find it when linking *before* it finds the msvcrt.lib that comes with later VC environments. [As an aside I have sent Octavian a copy of the latest Scintilla code, compiled with VC6] Regards, Rob.
Re: [perl-win32-gui-users] Win32::GUI::Scintilla V1.08
Will the new version of Win32::GUI::Scintilla be based on the latest version of Scintilla? I have seen that now Scintilla is very accessible for screen readers, but the older version which is used on the actual version of Win32::GUI::Scintilla is not accessible at all. The V1.08 build is based upon a relatively new version of Scintilla (Version 1.66, with the latest being Version 1.69 - see http://www.scintilla.org/) - do you still have problems with this version? Cheers, jez.
Re: [win32-gui] Re: [perl-win32-gui-users] Win32::GUI::Scintilla V1.08
Octavian Rasnita wrote: Will the new version of Win32::GUI::Scintilla be based on the latest version of Scintilla? Yes, the version I sent you uses Scintilla 1.68, which was the latest available when I looked a week or so ago. (although I see there's already a 1.69). Regards, Rob.
Re: [win32-gui] [perl-win32-gui-users] BrowseForFolder & Make New Folder
There's already an RFE for this: http://sourceforge.net/tracker/index.php?func=detail&aid=1342872&group_id=16572&atid=366572 Regards, Rob. Eric Nichols wrote: I've been trying to get the "Make New Folder" button to appear in the BrowseForFolder dialog. I think that BIF_NEWDIALOGSTYLE (0x0040?) needs to be set. Tried that with no such luck. According to Microsoft's info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/structures/browseinfo.asp OLEInitialize or CoInitialize must be done before calling the dialog. I tried this with no luck. My Code: Win32::OLE->Initialize(Win32::OLE::COINIT_OLEINITIALIZE); my $dir=$mw->BrowseForFolder(-root=>0x0040); Can anyone give me the correct couple of lines of code to make this work? Many thanks Eric --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd___ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
[perl-win32-gui-users] -singlesel
I know that the FAQ says: How can I prevent the user from choosing more than one item in a Listview? You can use the -singlesel option on the ListView to achieve what you want. However, this option seems to do nothing. Has anyone ever been able to actually do this? I even tried loading up the GUI Loft to see if it would work correctly there, but I get the same results. It doesn't seem to matter if you enable or disable this option, you can always pick multiple items in a listview. Greg
Re: [win32-gui] [perl-win32-gui-users] -singlesel
If I add -singlesel => 1, to the constructor for the listview_drag_drop.pl demo that is distributed with Win32::GUI, then it works fine for me. Perhaps you could post a short, complete example of what doesn't work for you (along with what version of Win32::GUI you are using)? Regards, Rob. Greg Dance wrote: I know that the FAQ says: *How can I prevent the user from choosing more than one item in a Listview?* You can use the -singlesel option on the ListView to achieve what you want. However, this option seems to do nothing.* Has anyone ever been able to actually do this?* I even tried loading up the GUI Loft to see if it would work correctly there, but I get the same results. It doesn't seem to matter if you enable or disable this option, you can always pick multiple items in a listview. Greg
Re: [win32-gui] [perl-win32-gui-users] -singlesel
Greg Dance wrote: [snipped to leave some options from Greg's post] -singlesel => 1, -style => WS_CHILD | WS_VISIBLE | 1, -fullrowselect => 1, -gridlines => 1, -checkboxes => 1, What I found is that the -style line is the culprit. When this is included the -singlesel option doesn't do anything. I'm not sure what the -style option is specifically doing, but that is the source of the problem. Several things to learn from this: (1) Short, complete examples are not just for the benefit of the audience that you post to; they often lead to solving (or at least narrowing down) the problem. (2) That's probably one of the reasons that the -style option generates a 'deprecated' warning (you are running with warnings on?) And for reference, the options that I've left above all do things with the control's 'style', and are processed in order. All the options except '-style', either add or remove style bits from a mask. '-style' clobbers the mask with a fixed value - it's useful if you know what you're doing, but dangerous (as you've discovered) otherwise. There are a number of ways this could be re-written so that it works, the easiest would be to move the -singlesel option after the -style option - but note that none of the styles used in the -style line are required by modern Win32::GUI versions: WS_CHILD and WS_VISIBLE are default options for a listview (and most, if not all controls), and I'm not sure what, if anything, setting bit 0 does. Glad you've sorted it. Regards, Rob.
RE: [win32-gui] [perl-win32-gui-users] -singlesel
Rob, I tried what you have below and it worked so I started stripping my sample down line by line until I figured it out. The listview I had looked like this: $Main->AddListView( -name => "BuildView", -singlesel => 1, -text => "hello world!", -left => 360, -top => 450, -width => 305, -height=> 100, -style => WS_CHILD | WS_VISIBLE | 1, -fullrowselect => 1, -gridlines => 1, -checkboxes => 1, -font => $normal_text, ); The bulk of this was just a cut and paste from a sample I had found on the web. What I found is that the -style line is the culprit. When this is included the -singlesel option doesn't do anything. I'm not sure what the -style option is specifically doing, but that is the source of the problem. Thanks! Greg -Original Message- From: Robert May [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 12:59 PM To: Greg Dance Cc: perl-win32-gui-users@lists.sourceforge.net Subject: Re: [win32-gui] [perl-win32-gui-users] -singlesel If I add -singlesel => 1, to the constructor for the listview_drag_drop.pl demo that is distributed with Win32::GUI, then it works fine for me. Perhaps you could post a short, complete example of what doesn't work for you (along with what version of Win32::GUI you are using)? Regards, Rob. Greg Dance wrote: > I know that the FAQ says: > > *How can I prevent the user from choosing more than one item in a > Listview?* > > > You can use the > > -singlesel > > option on the ListView to achieve what you want. > > However, this option seems to do nothing.* Has anyone ever been able > to actually do this?* I even tried loading up the GUI Loft to see if > it would work correctly there, but I get the same results. It doesn't > seem to matter if you enable or disable this option, you can always > pick multiple items in a listview. > > Greg >
RE: [win32-gui] [perl-win32-gui-users] -singlesel
Just an FYI... 1) I originally had the -singlesel as the last option in the list (after -style) and the problem still existed. 2) When I first started this little project I was running on an older version of Win32::GUI and it did not generate any depreciation warnings. It wasn't until I updated to 1.03 that I saw the warnings. The warnings when generated look like this: Win32::GUI: the -style option is deprecated! at C:/Perl/site/lib/Win32/GUI.pm line 603. It didn't tell me the line of my code that the -style option was depreciated and since I have a number of places where the -style option was used (not always in a listview) I wasn't sure which one it was complaining about. Thanks again for the help. Greg -Original Message- From: Robert May [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 3:05 PM To: Greg Dance Cc: perl-win32-gui-users@lists.sourceforge.net Subject: Re: [win32-gui] [perl-win32-gui-users] -singlesel Greg Dance wrote: [snipped to leave some options from Greg's post] > -singlesel => 1, > -style => WS_CHILD | WS_VISIBLE | 1, > -fullrowselect => 1, > -gridlines => 1, > -checkboxes => 1, > What I found is that the -style line is the culprit. When this is > included the -singlesel option doesn't do anything. I'm not sure what > the -style option is specifically doing, but that is the source of the > problem. Several things to learn from this: (1) Short, complete examples are not just for the benefit of the audience that you post to; they often lead to solving (or at least narrowing down) the problem. (2) That's probably one of the reasons that the -style option generates a 'deprecated' warning (you are running with warnings on?) And for reference, the options that I've left above all do things with the control's 'style', and are processed in order. All the options except '-style', either add or remove style bits from a mask. '-style' clobbers the mask with a fixed value - it's useful if you know what you're doing, but dangerous (as you've discovered) otherwise. There are a number of ways this could be re-written so that it works, the easiest would be to move the -singlesel option after the -style option - but note that none of the styles used in the -style line are required by modern Win32::GUI versions: WS_CHILD and WS_VISIBLE are default options for a listview (and most, if not all controls), and I'm not sure what, if anything, setting bit 0 does. Glad you've sorted it. Regards, Rob.
Re: [win32-gui] [perl-win32-gui-users] -singlesel
Greg Dance wrote: Just an FYI... 1) I originally had the -singlesel as the last option in the list (after -style) and the problem still existed. OK, I understand. This may have been the behaviour with older Win32::GUI versions, but not anything since at least 1.0 (I've double checked my memory against the current code, but could still be wrong). 2) When I first started this little project I was running on an older version of Win32::GUI and it did not generate any depreciation warnings. It wasn't until I updated to 1.03 that I saw the warnings. The warnings when generated look like this: Win32::GUI: the -style option is deprecated! at C:/Perl/site/lib/Win32/GUI.pm line 603. It didn't tell me the line of my code that the -style option was depreciated and since I have a number of places where the -style option was used (not always in a listview) I wasn't sure which one it was complaining about. Indeed. That problem is on the list of things to sort out. Thanks again for the help. You're very welcome. Rob.
