Re: [ql-users] WMAN progress
On 26 Nov 2002, at 17:25, P Witte wrote: iop.rptr does if you set the appropriate bits in the return vector. But Wman calls (wm.rptr) only respond to events (see the Qptr manual, pages 89 ff Window Manager Access Routines) Ah yes, you WERE talking about wm.rptr... AW events are entirely up to the programmer. My point is they are not processed by wm.rptr but by iop.rptr. This explains why there is no reaction to keystrokes defined in the main menu unless the AW happens to be a MSW. Again, I find this not to be the case. Just to be sure, I built a small application with QPTR, a wdw with an appsub window that is not a menu appsub window. I DO get the keystrokes for the Loose Items even if the pointer is in the appsub wdw. I can let you have the program if you want. Now, I know that QPTR uses a special action routine for appsub wdws that aren't menu appsub wdws (and where the call returns to basic at every pointer move keyclick in the appsub wdw), but, unless I'm wrong, the keystrokes for Loose Menu items get trapped by the WMAN RPTR loop before this action routine is ever called. I haven't tried this from assembler, though. Perhaps it's just EasyPtr's way of handling things? The simplest solution here is to use Dummy LIs in your main menu, as described earlier, and then use wm.rptr. However, this may not always be appropriate as MSWs can display a variable amount of data whilst the number of LIs must be pre-determined. Even though it would be possible to generate the LIs dynamically (after all they are size (0,0) generally at position (0,0) so colours etc don't matter) I don't like this solution of dummy LIs very much. I persume, though, that you couldn't do that from EasyPtr anyway, due to the way it builds the wdw (but I could be wrong here). (...) I'm sorry, I don'y use that. I've always found QPTR far easier - but it's a matter of taste! Having tried both, I definitely find EasyPTR easier to use - at least once I got to grips with it. Same here, but with QPTR - I think it's just a question of getting used to the thing. If you really prefer Qptr, you could still benefit from using the interactive design tools from EasyPTR - especially EasyMenu - if you could write a program to convert window definitions into Qptr-compatible SB statements. This might not be too difficult to do. A better way would be a menu designer for QPTR, of course... Would also make it easier for Assembler programmers (...) * I hope all this makes sense ;) It does to me. Wolfgang
Re: [ql-users] WMAN progress
Wolfgang Lenerz wrote: If you really prefer Qptr, you could still benefit from using the interactive design tools from EasyPTR - especially EasyMenu - if you could write a program to convert window definitions into Qptr-compatible SB statements. This might not be too difficult to do. A better way would be a menu designer for QPTR, of course... Would also make it easier for Assembler programmers For them there's EasySource which directly converts EasyMenu into assembler sources. Marcel
RE: [ql-users] WMAN progress
And for C68 programmers, there is EasyC from Bob Weeks of Pointer Products which turns EasyPtr menus into C68 stuff. If you can find a copy that is ! Cheers, Norman. PS. Don't anyone ask me how to do PE stuff in assembler - I have got absolutely no idea ! - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Marcel Kilgus [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 11:26 AM To: ql-users Subject: Re: [ql-users] WMAN progress Would also make it easier for Assembler programmers For them there's EasySource which directly converts EasyMenu into assembler sources. Marcel This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] WMAN progress
Norman Dunbar wrote: And for C68 programmers, there is EasyC from Bob Weeks of Pointer Products which turns EasyPtr menus into C68 stuff. Never heard of that, but IIRC EasyPtr 3 supports C programming directly. Marcel
RE: [ql-users] WMAN progress
Hi Marcel, indeed it does - there is a C68 library in the kit. However, the EasyC thing allows EasyPtr menus to be converted to the style used by Tony Tebby in his 'PE for C68' tutorial stuff - which I never ever got my head around. (Sorry Tony !) Cheers, Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Marcel Kilgus [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 12:07 PM To: ql-users Subject: Re: [ql-users] WMAN progress Never heard of that, but IIRC EasyPtr 3 supports C programming directly. Marcel This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] WMAN progress
??? 27/11/2002 3:59:38 ??, ?/? Wolfgang Lenerz [EMAIL PROTECTED] ??: Absurdly complicated stuff about W DEFs snipped ;-) A better way would be a menu designer for QPTR, of course... Would also make it easier for Assembler programmers (...) * I hope all this makes sense ;) It does to me. Well THERE'S GOT TO BE an easier way... ie an easier Interface for PE programs Right now the whole process looks so much like Visual Basic Window Definitions it's not even funny. I think the problem lies in trying to make a procedural language (SBasic) to work like a oO one. I looked into Jerôme's C68 PE articles and I got SCARED! Timothy Swenson's article on the same thing made the whole lot look a lot more easier but that didn't change the fact that the whole process is complicated in itself! In any way, I was thinking about what Wolfgang said too. A QPTR menu designer along the lines of EasyPTR would be great (It would be greater if it were free too :-). What would be even better is to create a good all-round IDE w/GUI designer that would remove all the menial work from the programmer completely. Yes like EasyPTR but adding up something like the Linker, a Basic compiler (Turbo seems great for the job ;-) a tool like MasterBasic an editor and a debugger all rolled into one. Hmm I'll look into it when I get some more time in my hands (after finals in two weeks). Phoebus
Re: [ql-users] WMAN progress
Phoebus Dokos makes some magical things to make me read } } } Well THERE'S GOT TO BE an easier way... ie an easier Interface for PE programs } } Right now the whole process looks so much like Visual Basic Window Definitions it's not } even funny. I think the problem lies in trying to make a procedural language (SBasic) to } work like a oO one. } } I looked into Jerôme's C68 PE articles and I got SCARED! Ok, please, what scared you ? I'm afraid to have provided too much dense information, did I ? } Timothy Swenson's article on } the same thing made the whole lot look a lot more easier but that didn't change the fact } that the whole process is complicated in itself! Agreed, there is a lot of control, hence a lot of data to provide, even to make a very mundane thing. } } In any way, I was thinking about what Wolfgang said too. } A QPTR menu designer along the lines of EasyPTR would be great (It would be greater if } it were free too :-). May I suggest, for the C68 inclined, a look at the Xmenu library ? (at least for Pop-up secondaries) it remove most freedom, just concentrating on the content and the behavior (but you then loose any fancy design).
Re: [ql-users] WMAN progress
On Wed, 27 Nov 2002, Phoebus Dokos wrote: Hehe it's not you. Just the concept of writing a Hello World type of program being aboyt 700 lines is enough to scare even the bravest! :-) Abstraction is very important. It's what the QL was all about in 1984. It's a shame that became less true over time. Abstraction increases the utility of the beast :o) imho Dave
Re: [ql-users] WMAN progress
Norman Dunbar wrote: And for C68 programmers, there is EasyC from Bob Weeks of Pointer Products which turns EasyPtr menus into C68 stuff. I think (not sure, as I ain't been there for a while) it was on TF's bulletin board (Tony?) If it works fairly well on modern systems, I'll add it to the PD library if I can get hold of a copy (assuming it's freeware or similar of course) Never heard of that, but IIRC EasyPtr 3 supports C programming directly. Yes, Easyptr 3 part 3 is what it was called when I sold it for Albin back in DJC days, not sure what name Roy and Jochen sell that part of the system under nowadays though. -- Dilwyn Jones
Re: [ql-users] WMAN progress
??? 27/11/2002 3:45:25 ??, ?/? Dilwyn Jones [EMAIL PROTECTED] ??: Don't wind him up...he sent me a few pictures of a Tyche ROM running on QemuLator or QLay (can't rememebr from memory) QLay it was... but sadly we haven't used the article following Tony's comments on Jonathan Oakley's connections,a s we haven't yet found how to contact Jonathan. Well i really don't know but that seems like a predecessor to Minerva but Lau could answer that I think but since it bears the Sinclair LOGO I would assume its covered by the Sinclair (ie Amstrad) copyright. In any case since QView has released all Minervas up to 1.89 maybe its covered by that as well... (and it really doesn't work as a replacement... I do want to test it though in a real QL to find out more about it) Sorry Phoebus...after your hard work (what we didn't want to do was encourage copying of Tyche ROMs until we got the copyright status clarified). Hehe that's okay... I am all for it although someone in this list should be able to either contact him, or know more details (maybe even Simon does... I'll email him later) SOme work is definitely needed on Easyptr and so on to help them make the most of GD2. What is surprising is that if you create a program in compiled BASIC with Easyptr 3 and mode 4 sprites etc it actually works in mode 32 on QPC anyway. It doesn't on Qx0... The graphics get all garbled... but that's not your fault of course :-) Maybe if you could use sprted by Jerôme??? The little PIC file viewer I mentioned when asking about window saves/restores with Easyptr a few days ago is now working nicely with mode 32 graphics (haven't got access to any graphics files from 8-bit or 24-bit systems to test) and even switches modes if needed (optional, since it can cause a mess) with a piece of code like: MCLEAR #0 DISP_COLOUR new_colour_depth_number MDRAW #0 which is crude and messes up other colours on the screen since the system does not do much colour conversions, which is why I suppose I have to clear the menus out, change the colour depth mode then redraw the menu. It sort of works, but makes life harder for other programs running as you might expect. Is there an official way of detecting GD2? As my program is compiled BASIC I just checked for DISP_COLOUR keyword being present until I know the correct way of checking. DISP_TYPE should return 33 or 32 As the PicView program is now working and needs to be compiled and instructions written, it'll shortly appear on my website for people to try out. It will also load screens and save them as PICs (i.e. adds the 10 bytes header) to encourage people to use PIC files as they are easier to deal with than screens. As my Q-Trans program is really still Beta, anyone aware of any significant bugs in it which need fixing? Seems rather more solid than I thought so far. Additionally to what I gave you earlier via private email, there's one additional small bug... Q-Trans crashes if you try to access a non-present device (ie a non linked Win drive) -- Dilwyn Jones
RE: [ql-users] One box or two
Duncan Neithercut wrote: My advice is to get both but as a human you might not notice major differences in performance between your two systems. The benchmarks also show that for running QDOS/SMSQ/E the Q60 is up there head to head with state of the art PC hardware. The question is how can SMSQ/E be run even faster on native hardware as PC hardware will go faster and faster as time goes by - multiple 68060 processors on a Q60 board? Short term: Faster RAM More overclocking An externel RAM cache Longer term: A new 680x0 processor (microcode?). http://tech-www.informatik.uni-hamburg.de/vhdl/models/m68000/m6800.vhd -- Tarquin Mills ACCUS (Anglia Classic Computer Users Society) http://www.planet14.sonow4u.co.uk/comp/accus/
Re: [ql-users] WMAN progress
On Wed, 27 Nov 2002 at 20:45:25, Dilwyn Jones wrote: (ref: 004d01c29657$41366440$0a26ff3e@blackpc) Don't wind him up...he sent me a few pictures of a Tyche ROM running on QemuLator or QLay (can't rememebr from memory) but sadly we haven't used the article following Tony's comments on Jonathan Oakley's connections,a s we haven't yet found how to contact Jonathan. Lau - are you still in contact. I have published the two emails I have, one of which was used to inform of his latest child a few years ago. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://www.firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] WMAN progress
On Wed, 27 Nov 2002 at 20:48:20, Dilwyn Jones wrote: (ref: 004e01c29657$421097a0$0a26ff3e@blackpc) Norman Dunbar wrote: And for C68 programmers, there is EasyC from Bob Weeks of Pointer Products which turns EasyPtr menus into C68 stuff. I think (not sure, as I ain't been there for a while) it was on TF's bulletin board (Tony?) I can't find it - at least by that name, or 'weeks' If it was there once it will still be there. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://www.firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
[ql-users] WMAN progress - Easyc
In-Reply-To: [EMAIL PROTECTED] I have Easyc here. It was bundled with the Tony Tebby example code on a PD disk from Ron Dunnett. Just fired it up and it did start, so if anyone wants a copy . I have also acquired Easyptr and use neither. They don't ever seem to do what I want and it has proved easier (eventually) to work from the TT example code and JH's code. Christopher Cave
Re: [ql-users] WMAN progress
With ProWesS, the COMPLETE code to write a 'Hello World' program in its
own movable window is :
#include ProWesS_h
void init()
{
PWObject window;
PWCreate(NULL,window,PW_TYPE_LOOSE_ITEM,
PW_LOOSE_TEXT, Hello World,
NULL);
PWActivate(window);
}
I have been telling everyone that ProWesS is much simpler than
QPTR/EasyPTR but nobody seems to care...
Regards,
Francois
On Mercredi, nove 27, 2002, at 12:38 America/Montreal, Phoebus Dokos
wrote:
Hehe it's not you. Just the concept of writing a Hello World type of
program being
aboyt 700 lines is enough to scare even the bravest! :-)
Now an additional library that takes care of the library (did I really
MEAN THAT?)
would probably solve the problem... ie
include pe_h
And then
PEWIndow something, (1, 2,3,4,5,6,)
would take care of the rest...
--
François Lanciault
[EMAIL PROTECTED]
Re: [ql-users] WMAN progress
Francois,
I wouldn't take the lake of response as a not caring. I for one don't
have much time to respond to many of these notes but do read them and
keep some for information.
My only reason to not use ProWesS for my project is that there would be
too many people with slow systems who might have an issue with speed.
Part of a proper desktop is the requirement that it doesn't get in the
way. If there is a speed issue, it would detract from many people
using it.
However, as you said, ProWesS is a very nicely put together sample of
object coding, greatly simplifying many tasks. I would encourage
anyone with a medium or faster system to try it out. Especially if
they have a lot of window coding to do or can use the font/graphics
capability.
Cheers,
jim
On Wednesday, November 27, 2002, at 08:22 PM, François Lanciault wrote:
With ProWesS, the COMPLETE code to write a 'Hello World' program in
its own movable window is :
#include ProWesS_h
void init()
{
PWObject window;
PWCreate(NULL,window,PW_TYPE_LOOSE_ITEM,
PW_LOOSE_TEXT, Hello World,
NULL);
PWActivate(window);
}
I have been telling everyone that ProWesS is much simpler than
QPTR/EasyPTR but nobody seems to care...
Regards,
Francois
[ql-users] pointer programming
For give me for breaking to subject off (was WMAN progress) but I am addressing only the programming in the pointer environment questions. I personally use C68 for 98% of my coding (a small part of assembly in some critical graphics pieces for pure speed). I use Easyptr for the menu generation and basic sprite tools, SpriteEdit for larger or high color sprites, and EasyC to convert the Easyptr stuff to 'C' code. For most windows this works quite well. I wish that EasyC used some different formatting and manually go through everything that it does but it does most of the work. If I had more time, I would write a simple piece to change its output to my preferred format or replace it with my own translation to 'C' - probably about the same amount of work. One caution for 'C' coders - if you are using the new GD2 calls and the message passing routines that are available in C68, I have found that several of the 'C' wrappers that call the native assembly routines are incorrect. Some of the corrections have been passed on (block drawing for example) and have been incorporated into the C68 release (make sure that you have the latest libraries). Unfortunately I haven't had a chance to do it with the rest of the ones that I have found. Here is a list of problem routines that I hit so far. I will submit my 'corrected' 'C' routines if I ever come up for air but QDT is taking precedence at this time. iop_flim sms_sevt sms_wext Jim On Wednesday, November 27, 2002, at 04:00 PM, Christopher Cave wrote: In-Reply-To: [EMAIL PROTECTED] I have Easyc here. It was bundled with the Tony Tebby example code on a PD disk from Ron Dunnett. Just fired it up and it did start, so if anyone wants a copy . I have also acquired Easyptr and use neither. They don't ever seem to do what I want and it has proved easier (eventually) to work from the TT example code and JH's code. Christopher Cave
