Re: [ql-users] EASYPTR Application windows
I can't help François with this particular problem, but one situation where I have encountered this kind of out of range error before (where a supposedly matching size window and item result in out of range error) is where the item is LEFT justified. In fact, often, left justified is not truly left justified, it is often one or two pixels away fromt he left of the window. You can sometimes see this by displaying a text object in a loose item, then MWINDOW to that loose item and MINPUT the same same text, it will appear to move slightly to the left. When you set justify for an object in Easymenu, you'll see a value of 0 for centred. If you set left, top, bottom justified you'll see a value of 1 shown. Left justify seems to be any non-zero offset from the left of the loose item. I don't fully understand what is going on, but know of it well enough to know that if I am trying to fit an item exactly, I have to actually allow a couple of extra pixels when designing the loose item or menu layout because of this small offset. -- Dilwyn Jones - Original Message - From: François Van Emelen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 30, 2005 3:57 PM Subject: [ql-users] EASYPTR Application windows Hi all, How can I avoid the folowing error: 'at line .. value out of range' MAWDRAW#3\3,grille$,0,0,0,cel_breedte%,12,1,1 where \3(,3) = application window #3 grille$ = a 3 dimensional array cel_breedte% = int array for the width of the individual columns (cel_breedte%(x) can be from 2 up to 384) The application window has been created with the option 'no menu'. The error pops up when the sum of cel_breedte%(x)+cel_breedte%(x+1)... exceeds somewhat the width of the application window. Any help is welcome. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.8.1/28 - Release Date: 24/06/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.8.8/37 - Release Date: 01/07/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EASYPTR Application windows
It seems to me if you expect to be able to see more than the window width you would have to send material to a notional piece of paper in the manner of a word processor or editor, to be viewed THROUGH your window. Conten to be stored in memory as an array, line by line. As to the third dimension ??? Seperate pages ? It's not fair to take the mickey out of Francois because his question is totally worth to be given some thoughts to. Normally the window manager cares for providing of scrolling and panning if the appwindow is too small for the array to be shown. But there are special cases where this fails and the problem of Francois is exactly such a case. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] EASYPTR Application windows
Hi all, How can I avoid the folowing error: 'at line .. value out of range' MAWDRAW#3\3,grille$,0,0,0,cel_breedte%,12,1,1 where \3(,3) = application window #3 grille$ = a 3 dimensional array cel_breedte% = int array for the width of the individual columns (cel_breedte%(x) can be from 2 up to 384) The application window has been created with the option 'no menu'. The error pops up when the sum of cel_breedte%(x)+cel_breedte%(x+1)... exceeds somewhat the width of the application window. Any help is welcome. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EASYPTR Application windows
At 16:57 30/06/2005 +0200, you wrote: Hi all, How can I avoid the folowing error: Puts me in mind of the Irishman who, when asked for directions, said If I was going there I wouldn't start from here. 'at line .. value out of range' MAWDRAW#3\3,grille$,0,0,0,cel_breedte%,12,1,1 It seems to me if you expect to be able to see more than the window width you would have to send material to a notional piece of paper in the manner of a word processor or editor, to be viewed THROUGH your window. Conten to be stored in memory as an array, line by line. As to the third dimension ??? Seperate pages ? where \3(,3) = application window #3 grille$ = a 3 dimensional array cel_breedte% = int array for the width of the individual columns (cel_breedte%(x) can be from 2 up to 384) The application window has been created with the option 'no menu'. The error pops up when the sum of cel_breedte%(x)+cel_breedte%(x+1)... exceeds somewhat the width of the application window. Any help is welcome. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.7/34 - Release Date: 29/06/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.7/34 - Release Date: 29/06/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Easyptr Move
I tried sending this once, I think it never got past our server for some reason. I got an email from someone who pointed out that some of the Launchpad programs can use the window outline and window content move facility of the new window manager and some can't (those just always use the standard window move icon method) This rather puzzled me because the programs were all compiled with the same Easyptr and QLiberator versions. I've since noticed that it's down to a difference in how the WMOV extension in Easyptr's toolkit works. (v3.50) If you set a loose item object to have the code '5' so that it uses system move, you can use any of the window manager methods. If you use WMOV there is only the old method available. You can't use any of the new methods. Sometimes you have to use WMOV. For example, the Launchpad clock runs in a MW_LINKed window so it has to be stopped before a move routine is called to move the main display. Something to consider adding to the wish list for any new Easyptr updates I suppose, especially if a trivial change, although hardly a high priority. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Easyptr Move
Dilwyn Jones writes: If you use WMOV there is only the old method available. You can't use any of the new methods. Sometimes you have to use WMOV. For example, the Launchpad clock runs in a MW_LINKed window so it has to be stopped before a move routine is called to move the main display. Something to consider adding to the wish list for any new Easyptr updates I suppose, especially if a trivial change, although hardly a high priority. In the mean time you can use my Wrezmov toolkit which was designed as a stopgap for exactly that problem.Available where? Knoware! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr
On Tue, 8 Mar 2005 at 14:06:05, Dave P wrote: (ref: [EMAIL PROTECTED]) On Tue, 8 Mar 2005, Roy wood wrote: Could be worse - could be Jochen and almost anything electrical. He is the only person I know whose washing machine has a software fault. No, he isn't. :) My washer would sometimes stop mid-cycle, and the LCD would display ##2##2##2##2##2isread The repairman who fixed it under warranty said the on-board microcontroller had a faulty EPROM, and that he would have to get a replacement. I offered, and he accepted, for me to download the image, and flash a 27512 I happened to have laying around. This gave me opportunities for abuse... (and saved him a trip ;) My washer now freaks the missus out by saying Hi Jimi instead of Door Open on the display when she opens the lid (which she's not likely to see as the lid obscures the LCD, but she noticed after a couple of months. She's convinced Sears are tracking her laundry habits ;) He he. It is the same size as Minerva. How about porting that. It should write clean code (8-)# Tony -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Am Tue, 8 Mar 2005 22:59:14 - hat Dilwyn Jones [EMAIL PROTECTED] geschrieben: Create a small menu, say one info window and one loose item. Do not MCALL, just MDRAW then try to MWINDOW to the loose item followed by MINPUT. Sometimes it works, sometimes it doesn't, sometimes it only works if the menu has not been changed since it was originally designed in Easymenu. Although to be fair I'm not sure it's a 'legal' routine: This is indeed an EP-bug. I have known it for years but never found it a real problem. In my programs loose Item no. 1 is always ESC. There is no need to give it another text or sprite. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] EasyPtr
My little colour selection technique using PALETTE_QL seems to work OK in the simple programs I've tried it in. That might be, but all PALETTE_QL settings are global! You're changing the colours for ALL jobs this way. Yes, I forgot to mention that. At least running mode 4 colour scheme jobs can then be any colour you want. But agreed, it wouldn't be a very nice thing to do! I can send you the EasyMenu version that is around if you want to try a proper System Palette approach instead. Yes please, that would be much appreciated to keep me going until an 'official' version is available. If by email, send it to dilwyn DOT jones AT tesco DOT net, I can download that one at work or at home. At the moment, the other email addresses are home only. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Hi Marcel, Is this all? Nobody else any problems? I won't promise anything, but if I don't know what's wrong I certainly cannot change it. I promise that I will never ever see you as THE person to ask for improvements of EasyPtr ;) but I am happy that you do it :) Okay then, one problem with the version of EaysMenu I have is, that there are problems with changing manually the size of the main window. First you cannot write numbers 999, while changing the window size with the mouse allows bigger ones. Second, x- y-coordinates of 0,0 (manually) crashes EasyMenu Then I'd like to have a version af Appman whose configuration block is okay, in all versions I have tried you can configure the path as often as you want, but the program doesn't accept it. This is extremely annoying. The other one is that Appman crashes the machine every now and then. But I suppose this is difficult to explore because it doesn't happen always and it is not at all clear, under which circumstances. When there are more problems, whom am I to ask then? ;))) Thanks a lot, without you the QL would be dead as a dodo. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] EasyPtr was movig sbasic
3) Application window scroll bar attributes cannot be set or changed without specifying a pre-set menu too. Part of the problem may be with the toolkit which seems to ignore or overwrite attributes added by hand later. This sounds a bit complicated, especially as all the application menu stuff has always been somewhat of a mystery to me ;-) I think I've ran into this problem too. I gave up, assuming I was doing something wrong. It was a long time ago, I haven't kept the example. Is this all? Nobody else any problems? I won't promise anything, but if I don't know what's wrong I certainly cannot change it. Append sprites to a code file, put those in memory while writing and testing in SBASIC. You'll find you can't refer to them by name while resident in memory, only by address. Only tested with mode 4 sprites. So you have to refer to a sprite called mysprite as SPRA(mysprite) instead - in other words, when sprites are resident appended to an extensions file, you have to refer to them by address rather than name. Last tested on the pre-Marcel v3.50 Easyptr. I asked Albin about this a couple of years ago and he said there was an issue with pointers to names in these situations and although he hadn't looked at the code at the time he feared it might be a big issue and recommended I stuck to referring to sprites by address rather than name. To be fair, referring to sprites by name appended to an extensions file in memory from interpreted BaSIC is not a situation which occurs often, in my case it only happened because of the complexity of the use of sprites in Launchpad. I am so pleased that some work is being done on Easyptr and promise I will be one of the first in the queue to pay for an update! I'll look forward to being able to specify system palette colours if nothing else, although the improved handling of high colour sprites will be a useful bonus too. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr
On Tue, 8 Mar 2005, Roy wood wrote: Could be worse - could be Jochen and almost anything electrical. He is the only person I know whose washing machine has a software fault. No, he isn't. :) My washer would sometimes stop mid-cycle, and the LCD would display ##2##2##2##2##2isread The repairman who fixed it under warranty said the on-board microcontroller had a faulty EPROM, and that he would have to get a replacement. I offered, and he accepted, for me to download the image, and flash a 27512 I happened to have laying around. This gave me opportunities for abuse... (and saved him a trip ;) My washer now freaks the missus out by saying Hi Jimi instead of Door Open on the display when she opens the lid (which she's not likely to see as the lid obscures the LCD, but she noticed after a couple of months. She's convinced Sears are tracking her laundry habits ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr
I can just hear Roy muttering Dilwyn and his PC again... Could be worse - could be Jochen and almost anything electrical. He is the only person I know whose washing machine has a software fault. -- Roy Wood The way Jochen has problems with domestic appliances, I'd be very surprised if Andrea allows him to put water and electricity into the same washing machine ;-) -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr
The repairman who fixed it under warranty said the on-board microcontroller had a faulty EPROM, and that he would have to get a replacement. I offered, and he accepted, for me to download the image, and flash a 27512 I happened to have laying around. This gave me opportunities for abuse... (and saved him a trip ;) My washer now freaks the missus out by saying Hi Jimi instead of Door Open on the display when she opens the lid (which she's not likely to see as the lid obscures the LCD, but she noticed after a couple of months. She's convinced Sears are tracking her laundry habits ;) Dave He he, I did something similar to my colleague's PC where I patched the configuration text in the sign-on of one of our Removals programs. Unfortunately, he mentioned it in front of the boss and I had to rather quickly patch it back to how it was. The beauty of having QPC2 to hand, it was possible to find the text, load it into S-Edit in binary mode, overwrite the text with Welsh equivalent (my colleague is not a Welsh speaker) and save it back out again without too much fear of damaging anything as long as I didn't change any lengths in the file. The configuration was probably a text file but I didn't want to risk it. For a couple of days he couldn't figure out why he was entering stuff in English and it came out in Welsh the following day when he signed back in. I think it's called Personalising Dave. Or in my colleague's case, revenge. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Is this all? Nobody else any problems? I won't promise anything, but if I don't know what's wrong I certainly cannot change it. Think the only other things which spring to mind are: You cannot create an application sub-window menu with MAWDRAW or MAWSETUP which only contains one item in the menu. Yes, see my Q-Trans files window lists for how I work around this. If I have a directory with no or only one file listed, I have to ensure that the array passed to MAWDRAW or MAWSETUP always has 2 or more items. If I have less than 2 items, I display 2 but make the status of the extra ones to unavailable. It gets a border when the pointer is over it, but cannot be selected. MITEM does not allow you to redraw the loose item - it should accept the , or \ separator in line with the other commands to force it to redraw the item. At the moment it ignores the separator. Yes, you have to use MSTAT% or some such command to force a redraw. One more VERY obscure problem. Create a small menu, say one info window and one loose item. Do not MCALL, just MDRAW then try to MWINDOW to the loose item followed by MINPUT. Sometimes it works, sometimes it doesn't, sometimes it only works if the menu has not been changed since it was originally designed in Easymenu. Although to be fair I'm not sure it's a 'legal' routine: MDRAW#0,menu MWINDOW #0,-1 t$=something MINPUT #0,t$ (I use it at one point in Launchpad and it refused to work at first, then I created the same menu from scratch and it now works, I have never been able to pin it down exactly). -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Rich Mellor wrote: You cannot create an application sub-window menu with MAWDRAW or MAWSETUP which only contains one item in the menu. I need example for that, as simple as possible. MITEM does not allow you to redraw the loose item - it should accept the , or \ separator in line with the other commands to force it to redraw the item. At the moment it ignores the separator. Hmm, in the sources there is a note: ;14.04.97 MITEM nachzeichnen OK (nachzeichen = redraw) So perhaps it is fixed but didn't get properly released. Is this an error? I have a note that WRES does not release MCALL - therefore any attempt to use MCALL after the WRES command will result in an IN USE error If it is a bug I need a small example. Doesn't sound very high priority, though. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Wolfgang Uhlig schreef: Am Sat, 05 Mar 2005 22:08:04 +0100 hat François Van Emelen [EMAIL PROTECTED] geschrieben: 230 MDRAW#3,mysuqces$ :REMark mawdraw#3,4 Oh Francois, what's that? I don't know but one SuQcess and that's the one of me and Bob Spelten ;) What's in a variable's name. Line 230 comes from my QLDBAS_bas programme; my front end for the DBAS engine. It's 4895 line(s) long, 297.492B once Qliberated. I'll show a demo in Eindhoven at the end of the month... if my laptop is repaired :( EasyMenu is not very good at displaying high colour sprites, you have to fool it by putting a 4/8 mode sprite in front of each high colour sprite. This is not true! Only if you want to have the sprites in mode 4 or 8, too. Wolfgang With my version of Easymenu (Easymenr_cde v3.50, ptrmenr_cde v3.50, easyptr_cde v3.50, easybmen_cde v3.03, easymenu_exe v3.06) the following line doesn't display the high colour sprites at all if they aren't 'glued' to a 4/8 colour sprite. 280 FOR xx= 30 TO 1 STEP -1:MITEM#3,-xx,-2,SPRA(xx):END FOR xx:MLIDRAW#3 But they are displayed correctly if 'glued' to a 4/8 colour sprite. All my sprites are created with a combination of Jérôme's Sprite Editor, PNGConv, BMP2SPRT_obj and chainsprites_bas except for my 4/8 mode sprite used as 'glue'. Is there something wrong with my sprites or in line 280? I suppose my version of Easymenu is the latest official version. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Wolfgang Uhlig writes: EasyMenu is not very good at displaying high colour sprites, you have to fool it by putting a 4/8 mode sprite in front of each high colour sprite. This is not true! Only if you want to have the sprites in mode 4 or 8, too. Just to confuse things a bit more: Loose items and sprites drawn by SPRW can be standard high colour sprites. However, the routines to display sprites in regular menus, such as MAWDRAW, cannot cope with these, and require a mode 4/8 sprite to be prepended to a hicolor one. The fix could be very simple if one were able to read the code, find the problem and re-assemble it again, but as mentioned before, some of those steps are not straight forward.. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
I have been using this for quite some time now, even in my Email reader. Easymenu can do much more than we first thought. You miss the point. It can't do much of this without quite a lot of lateral thinking and programming around limitations. This is exactly what people want corrected. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
P Witte wrote: 1) Manually added scaling flags are removed on re-loading a menu definition and may even crash the program. 2) System sprites cant be shown and other hicolour sprites are problematic. 3) Application window scroll bar attributes cannot be set or changed without specifying a pre-set menu too. Part of the problem may be with the toolkit which seems to ignore or overwrite attributes added by hand later. 4) When changing the sprite origen of a, if the pointer sprite is moved outside the window EasyMen crashes. OK, noted. But basically I was only going to address high colour problems, though if time permits and the job is simple enough I might look into some others. No promises though. A great stop-gap improvement to this program might be to allow a menu definition to be saved as an assembler file directly from the program (EasyAsm doesnt work in GD2) No, that is much too difficult. But EasySource can easily be made to be GD2 compliant. IIRC all that's needed is to change one branch instruction. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Dilwyn Jones wrote: 1. I can't change the colour of the border or main window unless I cover the main window with an info window. If Easyptr allowed, say, MWINDOW #0,0 for the main outline it might then be possible to change the main menu colour. Use system palette colours in the menu and define a private system palette (somewhat contradictory name, but every job can have its own system palette) before drawing the menu. No flashing, no poking in the window definition. MSETUP #0,mymenu:rem don't show original on screen REMark change colours before originals are drawn MCOLOUR #0,menu_element_number,colour_number MDRAW #0 : REM draw in new colours it might be possible for me to do what I want, whichis to allow users to specify colours in a config block and set these at runtime. Yes, easily possible using the mentioned method. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr
Am Sun, 6 Mar 2005 13:34:19 - hat Dilwyn Jones [EMAIL PROTECTED] geschrieben: You totally miss the point of my email. You Wrote: It would be useful if the menu colours could be changed at runtime. At the moment, once they are defined in the Easymenu layout, that's it, the colours are fixed unless you manipulate the colour palettes or whatever. And I say this is absolutely not true. Where do I miss your point? On the one hand you say: changing colours at runtime is _impossible_ and on the other hand: the windows are flashing (when I change the colour) Only one can be right, right? What I do see as a problem, is that you cannot define (system) colours in the official version of Easymenu and indeed have to find workarounds within the Basic program. With the unofficial version of Marcel this is not any problem any more. That's why I think that everybody should have it. Your flashing problem (QCoCo must be a pain for your eyes!) has a simple solution: Get a faster machine ;) Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
François Van Emelen wrote: Some functions/procedures need improvement. For example 'RPXL%' (returns the pixel colour at a given position) only works in QL colours. This is an SMSQ/E limitation. About TurboPtr: the demo George showed us in Eindhoven(QL2004) didn't convince me to abandon EasyMenu. Yes, I think the Menu generator is essential. But perhaps the toolkit could be used together with EasyMenu? I have no idea. the following line doesn't display the high colour sprites at all if they aren't 'glued' to a 4/8 colour sprite. Right, the sprite identifiers are hard coded into MITEM, pretty easy to change this, though. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Dilwyn Jones wrote: I'm not sure I can enter system palette colours in standard Easyptr can I? No, I thought you had the newer one, haven't really kept track of it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Marcel Kilgus writes: P Witte wrote: 1) Manually added scaling flags are removed on re-loading a menu definition and may even crash the program. 2) System sprites cant be shown and other hicolour sprites are problematic. 3) Application window scroll bar attributes cannot be set or changed without specifying a pre-set menu too. Part of the problem may be with the toolkit which seems to ignore or overwrite attributes added by hand later. 4) When changing the sprite origen of a, if the pointer sprite is moved outside the window EasyMen crashes. .. of a menu, OK, noted. But basically I was only going to address high colour problems, though if time permits and the job is simple enough I might look into some others. No promises though. Sorry, it wasnt intended as a shopping list. I just wrote down a few problems that I could think of. Great if you feel like doing something about it. Just your little tweak to allow palette colours to be used has been very helpful. A great stop-gap improvement to this program might be to allow a menu definition to be saved as an assembler file directly from the program (EasyAsm doesnt work in GD2) No, that is much too difficult. But EasySource can easily be made to be GD2 compliant. IIRC all that's needed is to change one branch instruction. That would be very useful! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr
I said I wasn't going to write more on this, but as this will be a bit
more positive, I thought I'd at least try to make amends for the
negative emails.
This listing shows one way of getting 8 colours of your choice in the
menus.
Using colours 0 to 7 (black, blue,...yellow, white) it uses the
PALETTE_QL extension to redefine those colours.
The example below enables menus to display in 8 shades of grey
(including black). You won't get more than 8 colours from an Easymenu
menu even in high colour mode, and all menus are subject tot he same
colours, but at least they can be any 8 colours from the range
available, not just the usual QL black green red and white (and blue
magenta, cyan and yellow if you like).
The colour number values have to be 'true' colours, the 24-bit values.
The example below uses 8 shades of grey instead of 8 colours. The
colour numbers are of course (red*65536)+(green*256)+(blue) where red,
green and blue can have values from 0 to 255 inclusive.
Lines 110 to 180 could be a configuration block set of values defining
or altering the colour scheme. In essence allows me to achieve at
least some of what I wanted, although it's recolouring rather than
specifying colours of item types.
The CHECK extension in line 200 simply checks for the presence of the
keyword PALETTE_QL, if it's not present the program uses the
pre-defined menu colours. There's plenty of equivalent keywords out
there such as EXISTS, I think Per Witte's website also has one
(FINDNAME% ???). It might be possible to check screen mode or whatever
else you feel might be necessary.
I haven't exactly tried it on any of my compiled programs, but I guess
if I added something like this to Launchpad you probably wouldn't be
stuck with white background and red and green (fixed mode 4-style
colour scheme). Programs which used a technique like this could
probably be configured to reasonably fit in with whatever colour
scheme your GD2 programs are set to.
100 REMark map the colours to grey shades
110 white = 255*65536+255*256+255
120 yellow = 216*65536+216*256+216
130 cyan= 180*65536+180*256+180
140 green = 144*65536+144*256+144
150 magenta = 108*65536+108*256+108
160 red = 72*65536+72*256+72
170 blue= 36*65536+36*256+36
180 black = 0
190 :
200 IF CHECK('palette_ql') THEN
210 REMark define the 7 colours starting from 0 (black)
210 PALETTE_QL 0,black,blue,red,magenta,green,cyan,yellow,white
220 END IF
230 :
240 MDRAW #0,win1_testmenu_men
250 :
260 REPeat loop
270 num = MCALL (#0)
280 IF num 0 THEN EXIT loop:REM click on a loose item to quit
290 END REPeat loop
300 MCLEAR#0
Dilwyn Jones
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: P Witte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 04, 2005 6:28 PM Subject: Re: [ql-users] EasyPtr was movig sbasic Snip Although, in the fullness of time, the tools that George has produced to go with TurboPtr, may become replacements for EasyMen, they are by no means there just yet - at least not last I looked. However, that is another possibility for the future. I think you can do most things with setw TurboTptr or Cptr that a programmer would want. So what do you think is missing? What do you think should be done to improve the suite? Snip Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: Wolfgang Uhlig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 04, 2005 8:33 PM Subject: Re: [ql-users] EasyPtr was movig sbasic P Witte [EMAIL PROTECTED] wrote: We can live without a good menu designer or a sprite editor, but not without a way of displaying and manipulating our windows and menus from within programs, so for me that is the main priority. As to me, I can live without a sprite editor because it's possible to create sprites in other ways. A menu designer à la Easymenu_exe is (and has always been) indispensable for me when writing my programs for the QL. This is why my disappointment is so great at the moment. You can design menus in setw in TurboPTR. George has also written a program to convert EasyPtr windows to TurboPTR You can them use them for C in Cptr as well. George is also considering adapting setw so it produces. data files for assembler. A little interest from the group will encourage him! When I started to write programs for/on the QL many years ago, it was because EP made it so easy. I was already a mouse-user when most QL-users still thought of a computer-mouse as the beginning of the end of the world and only Roy dared to have BUTTONS on his desktop ;) EP has been my companion and my motivation on the QL. Without it probably none of my programs would have seen the world and I would have left the QL-scene long ago. George also has tools in his suite to create buttons from pictures and setw automatically produces text buttons for programs. Setw enables you to produce menu buttons as well. During the last two or three years I have always hoped that anyone (especially Marcel) would update EP. In only _one_ of his long nights Marcel succeeded in bringing Easymenu to a state where it can work with colours and 3-D borders! Marcel says, it is not perfect yet. I say, it's so much better now and I would even pay for _this_ one, if he asked me to. I am convinced that there would be hardly any EP-owner and -user who would NOT pay for such a version. The ones I know, wouldn't. It is so frustrating and annoying that it cannot be given or sold to other users! I am frustrated because of all things, we urgently need to make the QL survive, software (good, interesting, funny, useful and whatever programs) is the most important. A colourful game and a new desktop are not more than a drop in the bucket. Please you people out there, who really have the knowledge to write utilities which enable us lower gods to write software, which make it really easy to create it, which just motivate us to make a start, please just do it! Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
P Witte schreef: SNIP Its a pity Albin is no longer interested in developing EP, but thats life. It needent be such a big task, though. IMHO EP could be split into three or four different projects: 1) EasyMen, 2) EasySprite, 3) the toolkit, 4) C-stuff. 1) EasyMenu: In fact I would be happy with the enhancements already available to some of you: a) the possibility to design the windows in high/palette/system colours. b) the possibility to resize those windows in Sbasic (your MSPRV_obj proves it is possible). 2) EasySprite: An upgrade is not really necessary as there are alternatives at our disposal: Jerôme's Sprite Editor,BMPSPRT_obj (Wolfgang Lenerz),Snatch (?) could be adapted to save in 'sprite format' instead of 'pic format' and for QPC2 users there is PNGConv (Marcel Kilgus). 3) the Toolkit: Some functions/procedures need improvement. For example 'RPXL%' (returns the pixel colour at a given position) only works in QL colours. Including the toolkit in SMSQE is not an option for me: its functions/procedures would be available from the start, that would probably make some existing programmes unuseable because of keyword clashes.( see the messages about 'RESET') C) C-stuff: No comments here as I'm limited to Sbasic. About TurboPtr: the demo George showed us in Eindhoven(QL2004) didn't convince me to abandon EasyMenu. SNIP We can live without a good menu designer or a sprite editor, I can't else I wouldn't wait for an upgrade. but not without a way of displaying and manipulating our windows and menus from within programs, so for me that is the main priority. Per Wolfgang Uhlig asked us to fix a price... Well, I'm willing to pay about 50 Euros for an upgrade. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
wolfgang mühlegger wrote: but why did he do it then? Just for fun. and why did he give it to beta-testers then? There were no beta testers. I just gave it to some people and said look, mom, without hands. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: wolfgang mühlegger To: [EMAIL PROTECTED] Sent: Friday, March 04, 2005 9:06 PM Subject: Re: [ql-users] EasyPtr was movig sbasic gwicks schrieb: Nevertheless Marcel has already made a considerable improvement to EasyPtr, but as yet it is only available to a few beta testers. A pity for this work to be wasted by not being available (for a payment) to a wider group of users. but why did he do it then? and why did he give it to beta-testers then? As I understand it the history is as follows: When QL-ers first started to program in GD2 colours, the possibility of upgrading EasyPtr was raised including a lot of discussion on this list. Just out of interest Marcel took a look at it and working through the night produced a version that could use GD2 colours directly. He sent copies to one or two people whom he knew were actively attempting to write programs in EasyPtr using the colours. I put beta-testers in inverted commas because this was probably not their intended role. At this stage there was some doubt over the legal position, which in itself led to a lot of misunderstanding because no one had thought of asking Albin. I understand that he is quite happy for the program to be upgraded. When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. This can be a bit of a pain in the neck if you have a lot of sprites in a program. (And we should remember that the new sprite technology means that we should be wanting to include more sprites and more sophisticated sprites in our programs.) I am not sure what changes have been made to the upgraded EasyPtr since I last saw it, but I can understand if Marcel says it is not yet ready for release. We have come to expect a high standard from Marcel, and thus we should respect his opinion on this and not pressure him to release an incomplete product. It would be helpful if we could have an indication how far EasyPtr has developed and what is left to do. Then the sort of suggestions that Per made could be considered. BTW this is just the sort of topic that could be discussed at Eindhoven on 18th June if we are successful in getting the After-Glow Show off the ground, Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
gwicks schreef: SNIP When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. This is not true. Once your window is ready, save it in the usual way. Create your XXX_cde file (ptrmenr_cde, window definition designed with Easymenu, and add all your sprites ). Of course the sprites have to be in the correct order (first sprite for Loose Item -1, 2nd sprite for Loose Item -2, and so on). In your Sbasic program you could do something like this: (extract from my Front End for DBAS) 230 MDRAW#3,mysuqces$ :REMark mawdraw#3,4 280 FOR xx= 30 TO 1 STEP -1:MITEM#3,-xx,-2,SPRA(xx): :END FOR xx:MLIDRAW#3 Et voilà. Of course you wouldn't see those sprites next time you load EasyMenu to modify a menu but you don't have to reload them each and every time. Mind you (correct English?) EasyMenu is not very good at displaying high colour sprites, you have to fool it by putting a 4/8 mode sprite in front of each high colour sprite. This can be done with a small sbasic program Wolgang Lenerz published somewhere (on this list or in QLToday).It is about 20 lines long and is called 'chainsprites_bas'. I have created tens of sprites with this method. I have been using this for quite some time now, even in my Email reader. Easymenu can do much more than we first thought. SNIP It would be helpful if we could have an indication how far EasyPtr has developed and what is left to do. Then the sort of suggestions that Per made could be considered. BTW this is just the sort of topic that could be discussed at Eindhoven on 18th June if we are successful in getting the After-Glow Show off the ground, That would be a good idea! Best Wishes, Geoff François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Geoff Wicks wrote: As I understand it the history is as follows: When QL-ers first started to program in GD2 colours, the possibility of upgrading EasyPtr was raised including a lot of discussion on this list. Just out of interest Marcel took a look at it and working through the night produced a version that could use GD2 colours directly. He sent copies to one or two people whom he knew were actively attempting to write programs in EasyPtr using the colours. I put beta-testers in inverted commas because this was probably not their intended role. At this stage there was some doubt over the legal position, which in itself led to a lot of misunderstanding because no one had thought of asking Albin. I understand that he is quite happy for the program to be upgraded. When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. This can be a bit of a pain in the neck if you have a lot of sprites in a program. (And we should remember that the new sprite technology means that we should be wanting to include more sprites and more sophisticated sprites in our programs.) I am not sure what changes have been made to the upgraded EasyPtr since I last saw it, but I can understand if Marcel says it is not yet ready for release. We have come to expect a high standard from Marcel, and thus we should respect his opinion on this and not pressure him to release an incomplete product. It would be helpful if we could have an indication how far EasyPtr has developed and what is left to do. Then the sort of suggestions that Per made could be considered. BTW this is just the sort of topic that could be discussed at Eindhoven on 18th June if we are successful in getting the After-Glow Show off the ground, Best Wishes, Geoff Well said as usual Geoff. I hope that any update to Easyptr would allow some changes in the colour handling on the toolkit extensions side as well. It would be useful if menu colours could be made to assume the new Window Manager colours in some form (standard appearances and all that), e.g. specifying a negative colour number or some special setting picked a standard window manager colour scheme or whatever. I haven't thought this through, I don't even know if it's possible/desirable. It would be useful if the menu colours could be changed at runtime. At the moment, once they are defined in the Easymenu layout, that's it, the colours are fixed unless you manipulate the colour palettes or whatever. It might be possible to hack around in the working definition to set the colours if someone was prepared to write such extensions, but I don't know if this sort of code could be achieved legally. The nice thing with Easymenu in particular is that you can just visually create menus without worrying too much about endless lists of data as you have to with some other older PE development tools. If you want to explicitly set loose item, menu, or window sizes you can do so, but don't have to. If you want to, you can just size them by appearance, especially if you use text loose items when you don't have to worry too much about pixel perfect fit and endless lists. We would need to get the resize flag mechanism implemented too, although there is an extension by Per Witte which will help with that for existing menus if you are prepared to play around with the working definition a bit. Which sums up the existing Easyptr - you have to think laterally and go the extra mile to achieve anything useful (ref. Wolfgang's colours article in QL Today Vol 8 Issue 5 page 8). Since Easyptr will probably be the source of the majority of any new applications, effort deserves to be focused on that a bit I'd have thought. I do hope that development does get going though, even if it turns out to be easier to write a similar new product than trying to rehash uncommented old code or whatever. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
gwicks wrote: At this stage there was some doubt over the legal position, which in itself led to a lot of misunderstanding because no one had thought of asking Albin. I understand that he is quite happy for the program to be upgraded. Yes, he basically said that anything I choose to do is fine with him. When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. Right. It was able to load the raw sprites, because then it just took that junk of memory, but when embedded into a menu it tried to make a copy of it and of course completely failed. This can be a bit of a pain in the neck if you have a lot of sprites in a program. (And we should remember that the new sprite technology means that we should be wanting to include more sprites and more sophisticated sprites in our programs.) Actually that was part of the problem. The sprite definition became so complex that it was a pain to support it for EasyMenu. As said, I have done most code now (which should ultimatively be part of SMSQ/E so others in this situation don't have to do it again), but it is not debugged. I am not sure what changes have been made to the upgraded EasyPtr since I last saw it, but I can understand if Marcel says it is not yet ready for release. We have come to expect a high standard from Marcel, and thus we should respect his opinion on this and not pressure him to release an incomplete product. That's exactly the point. At least without working sprite support it was just a nice toy, not fit for anything really. With it, it looks somewhat better. But I do have high standards for myself, especially if ever any money would change hands for it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Myself for another. jim On Mar 3, 2005, at 11:17 PM, François Van Emelen wrote: Roy wood schreef: In message [EMAIL PROTECTED], gwicks [EMAIL PROTECTED] writes Snip Easyptr is still a commercial program sold by Jochen and I On the subject of EasyPtr any news of a possible upgrade? The upgrade situation is not easy. I do have an updated version of Easymenu and Easysprite but they are by no means releasable as Marcel considers them unfinished. The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? I don't know how many but I would be one of them. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? I am a liittle bit astonished because AFAIR there were many people in Eindhoven 2004 already who pointed out that they would be willing to pay for an upgraded version of EasyPtr. Nevertheless nothing happens exept for the question in this group every now and then, whether there will be an upgrade or not. When I asked Marcel personally some weeks ago, he told me that he is not at all interested to do it. So what is true? I would definitely want to have an upgrade (and pay for it ofcourse) and think that we need it urgently. So, as far as I am concerned, please stop discussing it, fix a price for it and begin to DO it. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] EasyPtr was movig sbasic
Easyptr is still a commercial program sold by Jochen and I On the subject of EasyPtr any news of a possible upgrade? The upgrade situation is not easy. I do have an updated version of Easymenu and Easysprite but they are by no means releasable as Marcel considers them unfinished. The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? I'm definitely booking one for me, I use it all the time. I'd definitely pay for an upgrade, I have either a v3.05 or v3.50 (can't remember which, I think the latter) at the moment. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] EasyPtr was movig sbasic
I would definitely want to have an upgrade (and pay for it ofcourse) and think that we need it urgently. So, as far as I am concerned, please stop discussing it, fix a price for it and begin to DO it. Wolfgang Agreed, Wolfgang. QPCprint will appeal only to QPC2 users, so a small market. Marcel is confident enough of that, so I can't see there'd be a problem selling similar numbers of a new Easyptr better suited to GD2 use. Presumably, anyone like me who uses it to produce programs at the moment would buy an enhanced version. Easyptr in theory appeals to all QLers, but of course only to the programmers. The old Part 1 makes it quite easy to create simple menus, while Part 2 lets those confident enough to do more advanced things with it create those advanced programs. It also has a C68-related package, although I don't know if that's up to date and widely used. C68 and compiled basic are the only two widely used programming languages and tools for the QL (apart from assembler) and QPTR, SPACE, John Miller's Ptr Toolkit (or whatever it was called) and all those aren't widely used. Even TurboPTR doesn't get mentioned much, so I wonder if many people are using that? (I don't because I never get time to learn it!) In the absence of other widely used tools, I'd say we have to give strong consideration to developing Easyptr or something similar if developing Easyptr is considered too big a job. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Me too. Fabrizio - Original Message - From: Roy wood [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 04, 2005 1:08 AM Subject: Re: [ql-users] EasyPtr was movig sbasic In message [EMAIL PROTECTED], gwicks [EMAIL PROTECTED] writes - Original Message - From: Roy wood Subject: Re: [ql-users] movig sbasic Easyptr is still a commercial program sold by Jochen and I On the subject of EasyPtr any news of a possible upgrade? The upgrade situation is not easy. I do have an updated version of Easymenu and Easysprite but they are by no means releasable as Marcel considers them unfinished. The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 skype : royqbranch web : www.qbranch.demon.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Roy wood writes: The upgrade situation is not easy. I do have an updated version of Easymenu and Easysprite but they are by no means releasable as Marcel considers them unfinished. The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? Its a pity Albin is no longer interested in developing EP, but thats life. It needent be such a big task, though. IMHO EP could be split into three or four different projects: 1) EasyMen, 2) EasySprite, 3) the toolkit, 4) C-stuff. 1) Marcel has already done some work on this. If what he has done so far is reasonably stable and useful, why not release that for an upgrade fee (with Albin's blessing, of course)? It might even generate a few new sales of the whole package? Although, in the fullness of time, the tools that George has produced to go with TurboPtr, may become replacements for EasyMen, they are by no means there just yet - at least not last I looked. However, that is another possibility for the future. 2) I understand from Albin that this could be quite difficult to upgrade due to the way it is designed. It could be dropped altogether if there were viable alternative developments. How about Jerome's sprite editor? Or how about a more generalised spin-off of Jim's Icon Edit? 3) The EasyPointer keywords are mainly wrappers for the underlying Wman utilities. Wouldnt it be great if some (if not all) of those commands were to be included in SMSQE - or rather in Wman2? From my brief assessment of the toolkit, it seems to me the whole thing could be simplified and purified (to do away with the easymen Thing, for example) and improved. It neednt be compatible, but rather a replacement. The reason Im not enamoured of Qptr, the original PE toolkit, is the way it gets the user data into the Wman. It is superficially attractive to have all your data easily available and manageable from Basic. The problem for me is that there can be so much data to deal with that it swamps out the functional code. Although there are ways of minimising the hassle, it is still not ideal as, in effect, you have up to four copies of the window definition data in memory at the same time (DATA statement data gets put into arrays, which are copied to a Window Definition, which again is copied to a Working Definition). Also it is relatively fiddly to design and alter objects in this way. The EP approach of editing the design in a designated program and then linking the binary data to the code, compiled or interpreted, seems to me to be simpler, cheaper and more flexible. 4) Something for the C-fraternity to get their teeth into? So we come to the fraught question of who would do the work. Adding the toolkit to the Wman module could be an open project to go hand-in-hand with SMSQE development. The main thing would be to get off to a good start - perhaps initiated by one of the cognoscenti - and then building up the functionality over time. Even someone at my level could contribute there. We can live without a good menu designer or a sprite editor, but not without a way of displaying and manipulating our windows and menus from within programs, so for me that is the main priority. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
In message [EMAIL PROTECTED], Wolfgang Uhlig [EMAIL PROTECTED] writes SNIP I am a liittle bit astonished because AFAIR there were many people in Eindhoven 2004 already who pointed out that they would be willing to pay for an upgraded version of EasyPtr. Nevertheless nothing happens exept for the question in this group every now and then, whether there will be an upgrade or not. Well how many is many and what would you update ? The extensions all seem OK and the problems seem to lie in the menu and sprite generation software. Now if this is what needs to be done the answer may lie in wring a new program to generate menus and sprites in high colour mode that follow the EASYPTR standard and will work with the extensions. How hard or easy this is I cannot say When I asked Marcel personally some weeks ago, he told me that he is not at all interested to do it. I did not say he was interested in doing it just that he was the ideal person to do it. I gather that the code is very hard to work with as I said and I also get the impression that he does not want to do it. So what is true? I would definitely want to have an upgrade (and pay for it ofcourse) and think that we need it urgently. So, as far as I am concerned, please stop discussing it, fix a price for it and begin to DO it. It is all very well to say this but how do you get someone to do it? Now I realise that you will all say 'make it open source and then legions of talented programmers will spring from the stone that they shelter under to avoid the heat of the commercial world and do it' . Being realistic and seeing the vast amount of work these people have provided us with so far you can appreciate I am not holding my breath here. What I will say it this. As one of the two people who are licensed to sell this I will listen to anyone who may want to make a serious attempt at writing new menu and sprite generators for Easypointer and I am willing to be the vector for anyone who would like to sell these programs. In the case of the sprite generator I am sure Jim will give you the info you need to make a converter to allow you to export sprites from his QDT Icon program. I also think this is an important project and should tackled so I am happy to support it any way possible (except that I cannot directly pay anyone to do it). If someone would like to do it for free they would be free to distribute it so long as they do not include any of the copyright Easypointer components. Contact me if you want to take up the challenge. -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 skype : royqbranch web : www.qbranch.demon.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
James Hunkins schrieb: Myself for another. jim On Mar 3, 2005, at 11:17 PM, François Van Emelen wrote: Roy wood schreef: In message [EMAIL PROTECTED], gwicks [EMAIL PROTECTED] writes Snip Easyptr is still a commercial program sold by Jochen and I On the subject of EasyPtr any news of a possible upgrade? The upgrade situation is not easy. I do have an updated version of Easymenu and Easysprite but they are by no means releasable as Marcel considers them unfinished. The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? I don't know how many but I would be one of them. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm an another one: me too wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
P Witte [EMAIL PROTECTED] wrote: We can live without a good menu designer or a sprite editor, but not without a way of displaying and manipulating our windows and menus from within programs, so for me that is the main priority. As to me, I can live without a sprite editor because it's possible to create sprites in other ways. A menu designer à la Easymenu_exe is (and has always been) indispensable for me when writing my programs for the QL. This is why my disappointment is so great at the moment. When I started to write programs for/on the QL many years ago, it was because EP made it so easy. I was already a mouse-user when most QL-users still thought of a computer-mouse as the beginning of the end of the world and only Roy dared to have BUTTONS on his desktop ;) EP has been my companion and my motivation on the QL. Without it probably none of my programs would have seen the world and I would have left the QL-scene long ago. During the last two or three years I have always hoped that anyone (especially Marcel) would update EP. In only _one_ of his long nights Marcel succeeded in bringing Easymenu to a state where it can work with colours and 3-D borders! Marcel says, it is not perfect yet. I say, it's so much better now and I would even pay for _this_ one, if he asked me to. I am convinced that there would be hardly any EP-owner and -user who would NOT pay for such a version. The ones I know, wouldn't. It is so frustrating and annoying that it cannot be given or sold to other users! I am frustrated because of all things, we urgently need to make the QL survive, software (good, interesting, funny, useful and whatever programs) is the most important. A colourful game and a new desktop are not more than a drop in the bucket. Please you people out there, who really have the knowledge to write utilities which enable us lower gods to write software, which make it really easy to create it, which just motivate us to make a start, please just do it! Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: Roy wood To: [EMAIL PROTECTED] Sent: Friday, March 04, 2005 12:08 AM Subject: Re: [ql-users] EasyPtr was movig sbasic As the person who raised this yet again I would also be prepared to pay for an upgrade. At QL2004 I asked Marcel specifically about his attitude to the EasyPtr upgrade and he was quite definite that he did not want to be seen as Mr. EasyPtr. I interpreted this to mean that he does not want to be seen as the solution for every problem that arises in the QL community. I can sympathise with him on that. Nevertheless Marcel has already made a considerable improvement to EasyPtr, but as yet it is only available to a few beta testers. A pity for this work to be wasted by not being available (for a payment) to a wider group of users. One thought, if it would help to oil a few wheels, it would be possible to approach Quanta for financial help. I am writing this personally, but I sense a mood in Quanta that we have to look for other ways to support the members and the QL community other than through the magazine and shows, Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
gwicks schrieb: As the person who raised this yet again I would also be prepared to pay for an upgrade. At QL2004 I asked Marcel specifically about his attitude to the EasyPtr upgrade and he was quite definite that he did not want to be seen as Mr. EasyPtr. I interpreted this to mean that he does not want to be seen as the solution for every problem that arises in the QL community. I can sympathise with him on that. i understand that Nevertheless Marcel has already made a considerable improvement to EasyPtr, but as yet it is only available to a few beta testers. A pity for this work to be wasted by not being available (for a payment) to a wider group of users. but why did he do it then? and why did he give it to beta-testers then? wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: Roy wood Subject: Re: [ql-users] movig sbasic Easyptr is still a commercial program sold by Jochen and I On the subject of EasyPtr any news of a possible upgrade? Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
In message [EMAIL PROTECTED], gwicks [EMAIL PROTECTED] writes - Original Message - From: Roy wood Subject: Re: [ql-users] movig sbasic Easyptr is still a commercial program sold by Jochen and I On the subject of EasyPtr any news of a possible upgrade? The upgrade situation is not easy. I do have an updated version of Easymenu and Easysprite but they are by no means releasable as Marcel considers them unfinished. The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 skype : royqbranch web : www.qbranch.demon.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] EasyPtr
Marcel wrote: just came off the phone with Albin. In the course of the conversation we recognised that we would have met tomorrow anyway at a wedding of a mutual friend, so I will have some time to talk to him and sort this out. Any requests, suggestions? Make him rewrite EasyPtr... :-))) or at least give the sources free so that we can use your version of Easymenu officially. Wolfgang ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] EasyPtr
Wolfgang Uhlig wrote: Marcel wrote: just came off the phone with Albin. In the course of the conversation we recognised that we would have met tomorrow anyway at a wedding of a mutual friend, so I will have some time to talk to him and sort this out. Any requests, suggestions? Make him rewrite EasyPtr... :-))) or at least give the sources free so that we can use your version of Easymenu officially. Wolfgang That would be great. Frnçois Van Emelen ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] EasyPtr
Wolfgang Uhlig wrote: Make him rewrite EasyPtr... :-))) Not going to happen. He said if he were retired he'd probably do something, but as it is, he isn't and has enough paying things to do. Marcel ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
