Re: [ql-users] locking a window?
Unfortunately no, won't be able to get over there for this. But Roy and Jochen will both have updated copies that I hope they will be showing off. I suspect that someone could twist Roy's arm to demo it on the big screen. jim On Oct 3, 2004, at 1:17 AM, gwicks wrote: - Original Message - From: "P Witte" Subject: Re: [ql-users] locking a window? Looking very much forward to experiencing QDT in the flesh. Is it likely to be available at a show near me sometime soon? Are you at QL2004? I am hoping Roy will give a demonstration in glorious technicolour on the big screen. Best Wishes, Geoff http://members.lycos.co.uk/geoffwicks/ql2004.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
That is exactly what I do - separate executable program/window with the menu. jim On Oct 2, 2004, at 1:23 AM, John Sadler wrote: The answer is to follow emacs solution and make the menu a seperate executable program. The problem you are complaining about is in built into the pointer environment. All subwindows have to be within the main window whether you like it or not!. Of course you could reprogram the pointer environment so that this did not happen. - Original Message - From: "James Hunkins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 01, 2004 11:19 AM Subject: Re: [ql-users] locking a window? I had considered that but things like dropdown menus and error messages should have the original window left open so that you can have a reference. Not to mention, with folders, I would not like a full folder closing every time I wanted to run do a change to it or pick a sub-option. For somethings your suggestion may work but I am afraid not for the desktop that I am working on. Cheers, jim On Oct 1, 2004, at 2:37 AM, John Hall wrote: James Hunkins wrote: By the way, this mechanism is only being used when a particular sub-program is called and the calling window needs to be locked. Examples programs that need windows larger than the caller's window [drop-down menus, File and List selects, etc] and programs that will be directly changing something in the calling program so we would want to lock the calling program out [IconDraw for notebooks which will change the notebook's icon, Add Objects for folders, and notebooks for folders or Icons]. A possible alternative approach would be to close/remove the calling program's window(s) before the sub-program is called and then reinstating it/them when the sub-program exits... John ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
- Original Message - From: "P Witte" Subject: Re: [ql-users] locking a window? > Looking very much forward to experiencing QDT in the flesh. Is it likely to > be available at a show near me sometime soon? > Are you at QL2004? I am hoping Roy will give a demonstration in glorious technicolour on the big screen. Best Wishes, Geoff http://members.lycos.co.uk/geoffwicks/ql2004.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
In a message dated 02/10/04 23:41:20 GMT Daylight Time, [EMAIL PROTECTED] writes: > > In my FastFind program (currently still a sad misnomer) I use the Qmenu > File_select utility as an external program to avoid that utility determining > the size and layout of my program. It is, afterall, only incidental to it. I > think that works well. The file_select utility is included in the package > (not Qmenu, though) complete with instructions on how to use it in > your own programs. Id encourage others to use it or make their own version, > or package other utilities in a similar way, perhaps combined with some of > the techniques discussed under this thread. > > I wanted to use Qmenu to pick a file in a program which had small windows (which I certainly prefer to enormous ones which cover everything up). I also wanted to have Qmenu taking the whole screen because it is much better if possible to have the whole directory displayed rather than having to scroll through it. Since I did not want Qmenu to be a separate job (as for example with emacs) I had to solve the problem of subsidiary windows being inside the main one (and a good idea too!). What I did was to define the main window as variable up to the complete size of whatever screen it was on. I only used that large size when I wanted Qmenu to appear. When the file had been chosen I caused the main window to revert to its usual small size. George ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
The answer is to follow emacs solution and make the menu a seperate executable program. The problem you are complaining about is in built into the pointer environment. All subwindows have to be within the main window whether you like it or not!. Of course you could reprogram the pointer environment so that this did not happen. - Original Message - From: "James Hunkins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 01, 2004 11:19 AM Subject: Re: [ql-users] locking a window? > I had considered that but things like dropdown menus and error messages > should have the original window left open so that you can have a > reference. Not to mention, with folders, I would not like a full > folder closing every time I wanted to run do a change to it or pick a > sub-option. > > For somethings your suggestion may work but I am afraid not for the > desktop that I am working on. > > Cheers, > jim > > On Oct 1, 2004, at 2:37 AM, John Hall wrote: > > > James Hunkins wrote: > > > >> By the way, this mechanism is only being used when a particular > >> sub-program is called and the calling window needs to be locked. > >> Examples programs that need windows larger than the caller's window > >> [drop-down menus, File and List selects, etc] and programs that will > >> be directly changing something in the calling program so we would > >> want to lock the calling program out [IconDraw for notebooks which > >> will change the notebook's icon, Add Objects for folders, and > >> notebooks for folders or Icons]. > > > > A possible alternative approach would be to close/remove the calling > > program's window(s) before the sub-program is called and then > > reinstating it/them when the sub-program exits... > > > > John > > > > > > ___ > > QL-Users Mailing List > > http://www.quanta.org.uk/mailing.htm > > > > ___ > QL-Users Mailing List > http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm