Re: [ql-users] WMAN progress
Phoebus Dokos makes some magical things to make me read
} <[EMAIL PROTECTED]> ??:
}
} >Ok, please, what scared you ?
} >I'm afraid to have provided too much dense information, did I ?
}
} 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! :-)
Ok, but in the latest Xmenu, and only for a "Hello World", there
is a Report-like function which open a primary...... wonder if I updated
the website
} Now an additional library that takes care of the library (did I really MEAN THAT?)
} would probably solve the problem... ie
}
}
}
} And then
}
} PEWIndow something, (1, 2,3,4,5,6,)
}
} would take care of the rest...
Functions calls might be a little hard, but macro could be better for readability
(especially if the macro take care of size and justification: less parameters)
WM_litm my_looseitem[]= {
PE_LI_sprite(4,4,my_sprite,handler),
PE_LI_text(12,4,"Exit",handler),
{-1}
};
What do you think ?
Re: [ql-users] WMAN progress
François Lanciault makes some magical things to make me read
} 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...
It's just a bit too complex to enter and I cannot use Prowess for my sprite
editor...
Moreover, in the "Hello world", overruling the default C68 init() function is rather
agressive, IMHO.
I will think of Prowess again for my traditional little games, once I have solved my
current trouble with compiling SMSQ/E..., at least as exercices for my discovery of
Prowess.
Re: [ql-users] WMAN progress
> Moreover, in the "Hello world", overruling the default C68 init() function is > rather agressive, IMHO. The thigs is that ProWesS uses C, but it doesn't use the standard C libraries. Though it can be used in conjunction, it is intended to work without stdlib. In fact, this reduces the size of the programs considerably! Joachim
Re: [ql-users] WMAN progress - Easyc
EasyC is included on the QPTR Companion disk that is available as an optional extra for use with c68. Dave - Original Message - From: "Christopher Cave" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 28, 2002 12:00 AM Subject: [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
Wolfgang Lenerz writes: <> > > 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. There does seem to be a difference in behaviour between Qptr and EasyPTR. > I can let you have the program if you want. Yes please. > 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? I think you are right there. It appears that Qptr uses the AW's hit routine to transfer control back to BASIC, while EasyPTR simply loops. This is not an obvious use of an AW's 'hit routine'. It is only by re-reading the documentation for Qptr's BASIC keywords MK_APPW and RD_PTR that this becomes clear. Of course, its all there in the documentation, but that is only of use when you already know... > > 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 said nothing about dynamically generated dummy LIs in my piece above ;) As a possible solution to the problem you raised dummy LIs work as advertised. With Qptr, you may also have other options. <> > > 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 Assembler programmers can already use EasyMenu: A utility included with EasyPTR produces beautifully commented assembler source code from any (Easy) menu or sprite definition. Per
Re: [ql-users] WMAN progress
On 27 Nov 2002, at 17:53, P Witte wrote:
> Yes please.
OK, enclosed- load outptr_bin first. (lrespr)
Wolfgang
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
File information ---
File: p.zip
Date: 28 Nov 2002, 12:57
Size: 14642 bytes.
Type: ZIP-archive
p.zip
Description: Zip archive
Re: [ql-users] WMAN progress
Dilwyn Jones writes: <> > I haven't > yet been able to get EasySprite editor to work in mode 32, but use it > in QL colours mode to create the sprites, they display OK in menus in > mode 32. According to Albin Hessler it wont be EASY to fix EasySprite. I quote: # I know that EASYPTR does not work properly with the new # colours. EASYSPRITE actually does not write directly into # the screen buffer but writes the information into a blob # structure, which afterwards is drawn using the standard PE # tools. Anyway it writes into memory using the standard QL # colour format. So in fact EASYSPRITE would have to be # completely rewritten. Per
Re: [ql-users] WMAN progress
James Hunkins wrote
> 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.
>
In the PC / Unix world, a slow system is less than 500 - 1000 MIPs
ProWesS is fast on very slow systems (50 MIPS) and works well on
extraordinarily slow systems
> However, as you said, ProWesS is a very nicely put together sample of
> object coding
Wrong!!! It's an outstanding achievement.
> greatly simplifying many tasks.
Greatly simplifying, but still requiring programming skills
> >
> > 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);
> > }
> >
If you find this incomprehensible, try deciphering the standard C++ "Hello
World", I've tried and I failed. I think I'll stick with assembly language.
There are other simpler methods. How about
alert('Hello World') (Javascript)
Perhaps instead of pursuing WMAN, we could try an HTML / CSS window manager?
The main difficulties are the font and image rendering and Joachim has
really mastered that.
Tony Tebby
Re: [ql-users] WMAN progress / ProWesS
??? 28/11/2002 6:15:28 ??, ?/? "TonyTebby" <[EMAIL PROTECTED]> ??:
>>
>In the PC / Unix world, a slow system is less than 500 - 1000 MIPs
>ProWesS is fast on very slow systems (50 MIPS) and works well on
>extraordinarily slow systems
>
>> However, as you said, ProWesS is a very nicely put together sample of
>> object coding
>
>Wrong!!! It's an outstanding achievement.
>
>> greatly simplifying many tasks.
>
>Greatly simplifying, but still requiring programming skills
>
My objections are not in coding ProWesS stuff, which I find a great deal easier to
use than the PE.
They have to do with its appearance mainly. I am geared towards using the
Proforma engine only (like LineDesign IIRC). When only Proforma is used then the
results are outstanding.
IMHO, a improved PE (looking the way I want it... btw I have now finished all the
icons (pending Marcel's approval) and anyone who wants to take a look, I can send
you either Icons or sample Screenshots in PNG format) ;-) paired with PROforma
will provide a usable base for most types of Graphics-intensive applications and can
blow the socks off of Windows any day on any system :-) (Well sort of).
In such a case I think I could sacrifice ease of programming for extreme usability
(and good looks... which as everybody knows for me are extremely important).
The PE on the otherhand when run on a Mode 4 system has an elegance in its
'abstract look' but as it is currently, on a GD2 system... well it's butt-ugly :-D
(Exceptions to the above are the extremely well put-together apps of Jochen Merz
which look good anywhere...)
Don't get me wrong and I surely don't want to offend anyone but looks ARE
important for me at least :-)
>
>If you find this incomprehensible, try deciphering the standard C++ "Hello
>World", I've tried and I failed. I think I'll stick with assembly language.
>
Wait until you make a VC++ program using User32 ;-) hehe... now that's stuff not
even the designer of Visual Studio wouldn't understand :-)
>There are other simpler methods. How about
>
>alert('Hello World') (Javascript)
>
>Perhaps instead of pursuing WMAN, we could try an HTML / CSS window manager?
>
A presentable WMAN w/ PROforma can render HTML very nicely. HTML on the other
hand is VERY limited in describing the complexities of a windowing system. (Even
with CSS)... XML is another story, but who's going to write a parser?
>The main difficulties are the font and image rendering and Joachim has
>really mastered that.
>
True! (Although TTF would be greatly appreciated :-)
Phoebus
Re: [ql-users] WMAN progress
In article <[EMAIL PROTECTED]>, François
Lanciault <[EMAIL PROTECTED]> writes
>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...
The problem is the slower loading time for the system and slower running
on 'ordinary' QL equipment.
So the PE remains more convenient.
--
Malcolm Cadman
Re: [ql-users] WMAN progress
> >I have been telling everyone that ProWesS is much simpler than > >QPTR/EasyPTR but nobody seems to care... > The problem is the slower loading time for the system and slower running > on 'ordinary' QL equipment. > > So the PE remains more convenient. The slower loading is mainly caused by the precalculated fonts. When ProWesS is configured to have no precalculated fonts, the system will be much faster. This would however affect the performance later on. Another solution would be to store the precalculated in a file and load them from there when they are suitable. This could be done, but it needs some change in the code. Joachim
[ql-users] DD Discs
Is anyone interested? I have about 500 DD discs which have been used to program injection moulding machines which are now obsolete. They are free to anyone otherwise I am binning them. Any takers? John Taylor
Re: [ql-users] WMAN progress
> >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??? >From what I gather, it could be due to a problem in the sprite cache in certain versions of the OS, since if I understand correctly, sprites are internally converted to native (or whatever standard is used for the cache) then displayed in the current display type. If this is correct, there would be nothing I could do about Easyptr sprites. > 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) Hmm, wouldn't have noticed this as I don't have unlinked win/dos device son my system (all 8 win and dos devices used!). I'll try it at work where only dos1_,dos2_,win1_ and win2_ are used. -- Dilwyn Jones
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. > >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. Thanks Tony, I must be mistaken, anyone know where I could get a copy? -- Dilwyn Jones
Re: [ql-users] WMAN progress - Easyc
> 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 . Ah, thank you. A quick look at Ron's PD library catalogue shows it was the QPTR Companion disk Specials 6 (SP6). Also on my PD Library Gen48 disk. Hmmm, so what else do I have I don't know about ? ;-)) -- Dilwyn Jones
Re: [ql-users] WMAN progress
TonyTebby wrote:
> In the PC / Unix world, a slow system is less than 500 - 1000 MIPs
> ProWesS is fast on very slow systems (50 MIPS) and works well on
> extraordinarily slow systems
This is true. Nonetheless it has a response time of approximately one
second on my 400Mhz system, which is just too much, especially
compared to the not measurable response time of WMAN.
>> However, as you said, ProWesS is a very nicely put together sample of
>> object coding
> Wrong!!! It's an outstanding achievement.
Like many things it was too much ahead of its time.
>> greatly simplifying many tasks.
> Greatly simplifying, but still requiring programming skills
>> >
>> > 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);
>> > }
>> >
> If you find this incomprehensible, try deciphering the standard C++ "Hello
> World", I've tried and I failed. I think I'll stick with assembly language.
> There are other simpler methods. How about
> alert('Hello World') (Javascript)
> Perhaps instead of pursuing WMAN, we could try an HTML / CSS window manager?
> The main difficulties are the font and image rendering and Joachim has
> really mastered that.
> Tony Tebby
Marcel
Re: [ql-users] WMAN progress
Dilwyn Jones wrote: > From what I gather, it could be due to a problem in the sprite cache > in certain versions of the OS, Probably, yes. I did submit a fix for that bug over a year ago but it never went into SMSQ/E for Qx0 (i.e. QPC and Q40 differ in that respect since QPC2 2.03). The next SMSQ/E version will also incorporate it for the Q40. Marcel
Re: [ql-users] WMAN progress
Marcel Kilgus wrote: > This is true. Nonetheless it has a response time of approximately one > second on my 400Mhz system, which is just too much, especially > compared to the not measurable response time of WMAN. [snip] Argh, that was only a mail draft I thought I had deleted. Damnit. Marcel
Re: [ql-users] DD Discs
Hi John, they would be ideal for the next QL Today cover disk. Could you hand them over to Roy Wood? I could pick my share up from Roy whenever we meet next time... Cheers Jochen John Taylor wrote: > Is anyone interested? > I have about 500 DD discs which have been used to program injection moulding > machines which are now obsolete. > They are free to anyone otherwise I am binning them. > > Any takers? > > John Taylor
[ql-users] Programming in the Pointer Environment.
It would be great to have an integrated development environment for programming the pointer environment which was free. The bare bones have been developed by George Gwilt with his Tptr and Cptr. Tptr can be compiled by Turbo. Cptr can be compiled by C68. Window Definitions (as opposed to Working Definitions) can be created with Setf in Tptr. Gets rid of the kludge and resizing problems! Sprites for any mode can be created easily (except their may be a problem with QPC.) George will carry on developing the suite of programs if there is demand. At the minute he is just completing programs for Tptr which will read in a text file or a picture into a window and enable you to move around the file or picture like any normal GUI interface. So what about a group to develope an IDE using these tools?
Re: [ql-users] DD Discs
On Thu, 28 Nov 2002 at 19:35:40, John Taylor wrote: (ref: <[EMAIL PROTECTED]>) > >Is anyone interested? >I have about 500 DD discs which have been used to program injection moulding >machines which are now obsolete. >They are free to anyone otherwise I am binning them. Send them to a user group. ... for instance the London group had some items that were given to an 'octogenarian' (her words) visitor to the London show. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@.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 Thu, 28 Nov 2002 at 18:39:38, Dilwyn Jones wrote: (ref: <003e01c29719$3dce44e0$5630fd3e@blackpc>) > >> >> > 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. BTW BT have messed up again and cut off my BBS line. They are removing BT Highway, and for the extortionate sum of £50 I pay _them_ for the privilege, they have cut em off for two days! No wonder people leave them. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@.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 Jeudi, nove 28, 2002, at 01:37 America/Montreal, James Hunkins wrote: 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. It is the 'Many people' that I don't agree with. I think that, by now, MOST Ql users have migrate to SGC speed or faster. Those who still use 68008 Qls do not buy high end programs anyway and are happy with Quill and other pre 1990 programs. I am pretty sure that more than 90% of the potential buyers for QDT are on fast, GD2 ready systems. As for ProWesS not 'looking' good right now, there is no reasons not to enhance it visually; it is open source and already support GD2... I have nothing against PE/WMan programming. I have written a few programs using it. I just don't understand the lack of interest for ProWesS. Come on people, take the time to try it again on your new QPC/Q40 and realize that is it a fabulous Window Manager. Regards, Francois -- François Lanciault [EMAIL PROTECTED]
Re: [ql-users] WMAN progress
??? 28/11/2002 11:47:26 ??, ?/? François Lanciault <[EMAIL PROTECTED]> ??: > >It is the 'Many people' that I don't agree with. I think that, by now, >MOST Ql users have migrate to SGC speed or faster. Those who still use >68008 Qls do not buy high end programs anyway and are happy with Quill >and other pre 1990 programs. I am pretty sure that more than 90% of the >potential buyers for QDT are on fast, GD2 ready systems. > >As for ProWesS not 'looking' good right now, there is no reasons not to >enhance it visually; it is open source and already support GD2... > As Joachim had told me not so long ago, some things that I would like to see on it are tied to the PE and if this can't get update, short of a major re-write they wouldn't be possible If on the other hand the PE gets its makeover then there wouldn't be a reason not to enhance it further... Before anyone says anything I have PAID for ProWesS and the apps before it was open source so I really like it in order to buy it :-) I didn't just buy it for LineDesign but because the underlying principles are the way of the future for the QL I believe :-) >I have nothing against PE/WMan programming. I have written a few >programs using it. I just don't understand the lack of interest for >ProWesS. Come on people, take the time to try it again on your new >QPC/Q40 and realize that is it a fabulous Window Manager. > Well on the Q40 (at least mine) I tried to load it and it's impossible to get it to work. It seems that some bugs were re-introduced on SMSQ/E v.2y99 (I just found out) that makes it impossible to work... or maybe it's just my system... (I really don't know and it's very difficult for me to try all the combinations right now for lack of time). On the QXL and QPC on the other hand it works beautifully and I never had any problems with it. I use it and its apps constantly (Linedesign and PWFile) but I still have problems with its response. I would like to use the PROforma part of it used more however. (which I plan on getting into in depth (better late than never) after I sort out what's wrong with it on the Q40. It installed on SMSQ/E 2.91 but I can't really use it with 4 colours now... can I? :-) ) The combination of WMAN + PROforma seems more sensible due to the main advantage of WMAN being written in assembly... I am sending you a separate file to illustrate what MY preference would be :-) Phoebus
Re: [ql-users] WMAN progress
> Well on the Q40 (at least mine) I tried to load it and it's impossible > to get it to work. There has been a long history with incompatibilities between the Q40 and Prowess. I have managed to get it working, though and working correctly on the latest SMSQ/E (2y99 - else I wouldn't have released it!). For one thing, it is important to get the latest version of Prowess, as can be found on Joachim's site. You should really ditch your old Proforma/Prowess, including, especially, the configuration files (proforma_cfg, prowess_cfg - but keep a backup of these) and use only the one downloaded from the site. At the beginning, use the standard config files. I have found that they work without a hitch coming stright out of the "box", as they should. Then you can incorporate the changes you have made to your old config files. I know there was a line in there that causes Prowess (or rather Proforma IIRC) to crash, but I have lost my notes on this problem :-(((. I *think* it was something to do with the font caches, but am not sure. I have also found that sometimes it is easier to split up the "startup" file into two. My first one looks like this: "%% general ProWesS startup file &prg_setenv PWSDIR +$PWSDIR_prg;$PWSDIR_ext;$PWSDIR_mine %% first executable thing which is needed &rext rext %% load button frame (if doesn't exist) %% rext button_rext "Button Frame" %% already in SMSQ/E %% load DATAdesign engine %% rext engine_rext DATAdesign.engine %% already loaded %% load PROforma library pf_PROforma $PWSDIR_mine &wait "PROforma DLL" " and the second one: " %% general ProWesS startup file &prg_setenv PWSDIR +$PWSDIR_prg;$PWSDIR_ext;$PWSDIR_mine %% load ProWesS library pw_ProWesS $PWSDIR_mine &wait ProWesS %% load some useful executable things rext loader rext setenv rext request rext cbutton rext mbutton rext reader rext calc rext rconfig &wait "ProWesS reader" %% actually set up standard system %% personal_ldr %% mbutton intro -name "ProWesS - start here" -wait " I start them up with something like: EX dev1_prowess_prg_loader;"dev1_prowess_startup_1" and EX dev1_prowess_prg_loader;"dev1_prowess_startup_2" at different stages of my boot process. I load the same boot for QPC and the Q60, and Prowess works on both systems. (a small advertisement here : I've noticed that the standard distribution doesn't seem to included sprite_pfd, which enables you to display normal PE sprites and is needed for, e.g. Agenda. It can be obatined from me). > but I still have problems with its response. I must admit that I do, too. It is not a question of slow loading on bootup - that is not a problem for me as I load so many things on boot that I don't even notice Prowess. However, I think that Joachim's answer about precalculated fonts is the direction to look at. This should make things a bit faster. It is true, however, that opening new windows under Prowess is noticeably slower than under WMAN. Here at the office, I use QPC with a 730 Athlon and there is a noticeable lag when opening new windows (e.g. under Agenda). Perhaps this is something that can be speeded up. > would like to use the PROforma part of it used more however. (which I > plan on getting into in depth (better late than never) after I sort > out what's wrong with it on the Q40. It installed on SMSQ/E 2.91 but I > can't really use it with 4 colours now... can I? :-) ) I hope the above help! I use the Proforma part every day, since I print my invoices with it directly from Basic onto a PCL compatible laser printer. Really great stuff, that! > The combination of WMAN + PROforma seems more sensible due to the main > advantage of WMAN being written in assembly... > > I am sending you a separate file to illustrate what MY preference > would be :-) Good Wolfgang
Re: [ql-users] DD Discs
In a message dated 28/11/02 19:36:27 GMT Standard Time, [EMAIL PROTECTED] writes: Is anyone interested? I have about 500 DD discs which have been used to program injection moulding machines which are now obsolete. They are free to anyone otherwise I am binning them. Any takers? I would definitely be interested in 50 or so of them, please John :-) -- Rich Mellor RWAP Software 35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JH TEL: 01977 610509 http://hometown.aol.co.uk/rwapsoftware
