Re: [ql-users] Easyptr MAWDRAW
In a message dated 20/04/02 16:41:41 GMT Daylight Time, [EMAIL PROTECTED] writes: Anyone any idea will app window menus in Easyptr will not display a single item list (1x1) correctly? Dilwyn, I have come across the same problem some time ago... can't remember my work-around, but think that I added line of spaces as the next entry in the array and simply set it to unavailable... Rich Mellor RWAP Software 7 Common Road, Kinsley, Pontefract, West Yorkshire, WF9 5JR TEL: 01977 614299 http://hometown.aol.co.uk/rwapsoftware
Re: [ql-users] Easyptr MAWDRAW
Dilwyn Jones writes: I'm having a spot of bother with Application Window menus in Easyptr - can anyone help? If I set up a simple menu in app window 1 based on an array like DIM array$(36,200) and call it with MDRAW #0,flp1_mymenu_menu MAWDRAW #0,1,array$ all seems well. Even if I split the array, it seems to work: MAWDRAW #0,1,array$(0 to 10) What doesn't seem to work though is when it stops being a 2 dimensional array: MAWDRAW #0,1,array$(0 to 0) This is used to display and select a list of filenames on a disk and the problem happens when there is only one file on a disk (see my MakeDirs and SystemSet program file menus). I am currently using a workaround based on: MAWDRAW #0,1,array$(0 to 0+(number_of_files=1)) IF number_of_files = 1 THEN REMark set status of second item in list to unavailable stat% = MSTAT%(#0,65536*2+1,-1) END IF I use a similar workaround ;) mawsetup#cm, 1, qseld$(c0% to qcount% + (qcount% = c0%)) mstat#cm, 1, qstat%(c0% to qcount% + (qcount% = c0%)) Same problem with the other MAWDRAW/SETUP parameters and MSTAT. The only fix is for someone to update the package. Is that going anywhere? My offer of the loan a fine pair of Sheffield thumb screws was never called upon. Per
RE: [ql-users] EasyPtr
On 10 Apr 2002, at 13:52, Claude Mourier 00 wrote: Moi, je me contenterai de la version française ;-) D'accord, cela mettra un peu de temps de la rechercher dans mes fichiers archvivés... Après le weekend. Wolfgang
RE: [ql-users] EasyPtr
Merci par avance. Claude -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Envoyé : jeudi 11 avril 2002 10:37 À : [EMAIL PROTECTED] Objet : RE: [ql-users] EasyPtr On 10 Apr 2002, at 13:52, Claude Mourier 00 wrote: Moi, je me contenterai de la version française ;-) D'accord, cela mettra un peu de temps de la rechercher dans mes fichiers archvivés... Après le weekend. Wolfgang
RE: [ql-users] EasyPtr
-Original Message- From: P Witte [mailto:[EMAIL PROTECTED]] Subject: Re: [ql-users] EasyPtr I think youve hit apon the only conceivable solution; I mean, if I can do it and you cant, you must be as thik as two short planks ;) Or one very long one :o) And I can't spell 'thick' either ! Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
RE: [ql-users] EasyPtr
On 9 Apr 2002, at 20:20, Timothy Swenson wrote: Sometimes it's easier to learn by comparing the same general topic between computer systems. I started learning Windowing by reading on Perl/TK and comparing it with the Pointer Interface. It helps a little bit, but the data constructs and terms are very different. I've also tried understanding the QDOS kernel my learning the Unix kernel. Quite a number of years ago, I wrote a new explanation of the pointer interface and how to program it in QPTR. Unfortunately, it's all in French. Would somebody care to translate that? Wolfgang
Re: [ql-users] EasyPtr
On 9 Apr 2002, at 11:57, P Witte wrote: Youre quite right. The only wee difference is that of designing graphical objects intellectually or visually ;) Perhaps I'm more the cerebral type, then... More seriously, when designing most programs, I try to get a QPAC2 style look anyway. There is not much visual invention there... Also, I find that I have to envision the objects I want to design anyway (e.g. for The Wall), and having a more visual interface doesn't help me there. Then it's just a question of placing them - and that is pretty easy, anyway. Wolfgang
Re: [ql-users] EasyPtr
In message 001301c1dfa8$4bdcb5e0$0200a8c0@epsilon, P Witte [EMAIL PROTECTED] writes Dilwyn Jones writes: take on this task. I myself would be willing to do something for the (English) manual, if wanted. A note of caution: when I last spoke to him he said he had no English manual for it! I definitely have a comprehensive English manual! If Albin doesnt have one anymore, Ill be able to help out. It requires a bit of de-Germanisation and perhaps some streamlining (and any new features would have to be added ;)) Fear not! The Brits can have it in the only foreign language they understand: English! I have already done this and I have it here. It is the one I currently use for sale. -- Roy Wood Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!) Mobile +44(0)7836 745501 Web : www.qbranch.demon.co.uk
Re: [ql-users] EasyPtr
On 8 Apr 2002, at 19:59, Phoebus Dokos wrote: Seriously now, between what I saw Wolfgang and Marcel achieving with QPTR and EasyPTR respectively... I agree that at least ONE PTR toolkit (either) should be in one's arsenal :-) Oh but Marcel had the idea, not me. It's just a question of what you're used to. I never used EasyPtr, and found QPTR easy once I understood the concepts behind the PE. Wolfgang
Re: [ql-users] EasyPtr
Dilwyn Jones writes: take on this task. I myself would be willing to do something for the (English) manual, if wanted. A note of caution: when I last spoke to him he said he had no English manual for it! I definitely have a comprehensive English manual! If Albin doesnt have one anymore, Ill be able to help out. It requires a bit of de-Germanisation and perhaps some streamlining (and any new features would have to be added ;)) Fear not! The Brits can have it in the only foreign language they understand: English! Per
Re: [ql-users] EasyPtr
Wolfgang Uhlig writes: As far as I know, Marcel will try to get in contact with Albin in order to get him to correct and improve some things. But even so, if there is a possibility to do things, I am willing to contribute in any way I can. Concerning the german comments, if there are problems of understanding I could help. Perhaps Marcel knows differently, but I have the definite impression that Albin is not intending to do any more work on EasyPTR. I would of course love to help, but knowing my limitations, it would be foolish of me to step in where even the wise would hesitate to enter ;) BTW Welcome to the group! Per
RE: [ql-users] EasyPtr
I've had problems with both - never understood QPTR at all, docs were cr4p to say the least. Still got it somewhere - unused and as far as I can see, unusable. Even some of the demos (sprite editor) just give a no-entry pointer and hang. Not very helpful. As for DifficultPTR, well, Dilwyn knows the fun I had with that way back. When I eventually figured some of it out, I wrote it up in Quanta - and still use those notes today (!!!) when I try to do things. Then there was the C68 interface - again, too 'strange' for me to figure out. Maybe I'm too thik to be a programmer :o) Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 10:17 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] EasyPtr It's just a question of what you're used to. I never used EasyPtr, and found QPTR easy once I understood the concepts behind the PE. This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
RE: [ql-users] EasyPtr [OT]
-Original Message- From: P Witte [mailto:[EMAIL PROTECTED]] Subject: Re: [ql-users] EasyPtr Fear not! The Brits can have it in the only foreign language they understand: English! Q. What do you call someone who speaks 3 languages ? A. Tri-lingual. Q. What do you call someone who speaks 2 languages ? A. Bi-lingual. Q. What do you call someone who speaks 1 languages ? A. British. Why should we have to learn anything else - you all speak English fine, except maybe the Americans - tee hee ! (To all Americans, that was a joke - don't flame me (again) please !) Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
RE: [ql-users] EasyPtr [OT]
I always think the right answer was : French -Message d'origine- De : Norman Dunbar [mailto:[EMAIL PROTECTED]] Envoyé : mardi 9 avril 2002 11:32 À : '[EMAIL PROTECTED]' Objet : RE: [ql-users] EasyPtr [OT] -Original Message- From: P Witte [mailto:[EMAIL PROTECTED]] Subject: Re: [ql-users] EasyPtr Q. What do you call someone who speaks 1 languages ? A. British.
RE: [ql-users] EasyPtr [OT]
Nah, when I was in Paris, my wife did all the talking - she speaks it quite well - but everyone just said 'it's ok, we speak English' :o) Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Claude Mourier 00 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 10:34 AM To: '[EMAIL PROTECTED]' Subject: RE: [ql-users] EasyPtr [OT] I always think the right answer was : French This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
RE: [ql-users] EasyPtr
... Then there was the C68 interface - again, too 'strange' for me to figure out. Maybe I'm too thik to be a programmer :o) Nah, it's just the windows concept of programming. I never got to grips with Windows programming on PCs or X-Windows. And as for C++ and Object Disorientated programming, well... Don't worry, fashions change, people will flock back to command line interfaces as something new, and realize how much more intuitive they are. Then our traditional programming skills will be sought after again. ;O) Ian. -Original Message- From: Norman.Dunbar Sent: 09 April 2002 10:22 To: ql-users Cc: Norman.Dunbar Subject: RE: [ql-users] EasyPtr I've had problems with both - never understood QPTR at all, docs were cr4p to say the least. Still got it somewhere - unused and as far as I can see, unusable. Even some of the demos (sprite editor) just give a no-entry pointer and hang. Not very helpful. As for DifficultPTR, well, Dilwyn knows the fun I had with that way back. When I eventually figured some of it out, I wrote it up in Quanta - and still use those notes today (!!!) when I try to do things. Then there was the C68 interface - again, too 'strange' for me to figure out. Maybe I'm too thik to be a programmer :o) Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 10:17 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] EasyPtr It's just a question of what you're used to. I never used EasyPtr, and found QPTR easy once I understood the concepts behind the PE. This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: [ql-users] EasyPtr
Wolfgang Lenerz writes: Seriously now, between what I saw Wolfgang and Marcel achieving with QPTR and EasyPTR respectively... I agree that at least ONE PTR toolkit (either) should be in one's arsenal :-) Oh but Marcel had the idea, not me. It's just a question of what you're used to. I never used EasyPtr, and found QPTR easy once I understood the concepts behind the PE. Youre quite right. The only wee difference is that of designing graphical objects intellectually or visually ;) Per
[ql-users] EasyPtr
Hiall, You all know the super EasyPTR suit of programs and utilities from Albin Hessler? In response to my query, Albin writes that he would be happy to supply the source code to a person or persons willing to update and upgrade them! Most of this code is written in assembler with comments in German. I dont know what arrangement is envisioned, as this is still a commecial program (available from JMS). If you are interested, please get in touch with Albin yourself (If you dont already have his email address you can mail me privately for it, or to pass on a message). I really hope that there is someone with the time, inclination and ability to take on this task. I myself would be willing to do something for the (English) manual, if wanted. If the QL is to survive we need a steady supply of new programs. To realise that, we need good tools! EasyPTR is such a tool. We cannot afford to let it become obsolete! If you already know what EasyPTR is and the issues involved, please skip to my sig right now ;) EasyPTR is a suit of tools to help build Pointer Environment-enabled (PE) programs. EasyMenu lets you interactively create the program screens, with pop-up and pull-down menus, buttons, sprites and other components. The alternative is to write Window Definitions in assembler, or more clumsily but a wee bit more simply, with the Qptr toolkit by TT. The objects thus created can be manipulated from S*Basic, C and assembler, thanks to libraries of functions for these languages. Run-time libraries are available for inclusion in your programs - free for free programs, and for a miniscule unit fee for commercial ones. EasySprite allows the easy creation of sprites, blobs and patterns, while other programs and toolkits help with managing the various objects and components in various ways. In other words: EasyPTR is an essential utility for producing PE programs for the QL accross all platforms! However, EasyPTR is getting a bit long in the tooth. There are a few bugs that need sorting out and, although the output is compatible with all current Qdos/Smsq versions there are issues with some EasyPtr components on later versions of Smsq/E. Finally, when PE has been upgraded to handle the new colour modes, EasyPTR will require and extensive revamp to cope with them too. This could be a major undertaking. No self-respecting Tinkerer should be without EasyPTR! Per
Re: [ql-users] EasyPtr
Hi Per and all the others, If the QL is to survive we need a steady supply of new programs. To realise that, we need good tools! EasyPTR is such a tool. We cannot afford to let it become obsolete! I am absolutely of the same opinion! Finally, when PE has been upgraded to handle the new colour modes, EasyPTR will require and extensive revamp to cope with them too. This could be a major undertaking. As far as I know, Marcel will try to get in contact with Albin in order to get him to correct and improve some things. But even so, if there is a possibility to do things, I am willing to contribute in any way I can. Concerning the german comments, if there are problems of understanding I could help. No self-respecting Tinkerer should be without EasyPTR! Correct! Look at what can be done already, even with colours, by downloading the Qcolour-suite from Thierry's, Jochen's or Dilwyn's website. Wolfgang Uhlig
Re: [ql-users] EasyPtr
At 02:11 ìì 8/4/2002, Per wrote: No self-respecting Tinkerer should be without EasyPTR! Ouch... I knew I was lacking something... apparently that's self respect ;-) hehehehe Okay, okay I'll buy it :-) Seriously now, between what I saw Wolfgang and Marcel achieving with QPTR and EasyPTR respectively... I agree that at least ONE PTR toolkit (either) should be in one's arsenal :-) Phoebus
Re: [ql-users] EasyPtr
In message 001801c1df29$4c17dcd0$0200a8c0@epsilon, P Witte [EMAIL PROTECTED] writes Hiall, You all know the super EasyPTR suit of programs and utilities from Albin Hessler? In response to my query, Albin writes that he would be happy to supply the source code to a person or persons willing to update and upgrade them! Most of this code is written in assembler with comments in German. I dont know what arrangement is envisioned, as this is still a commecial program (available from JMS). And Q Branch. If you are interested, please get in touch with Albin yourself (If you dont already have his email address you can mail me privately for it, or to pass on a message). I really hope that there is someone with the time, inclination and ability to take on this task. I myself would be willing to do something for the (English) manual, if wanted. I have the English manual. I would also like to suggest that Rich Mellor be appointed to take on the task of updating the program. -- Roy Wood Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!) Mobile +44(0)7836 745501 Web : www.qbranch.demon.co.uk
Re: [ql-users] Easyptr 3
Thank you. The best solution so far has been to avoid using the sprite name in commands like MITEM and SPRA, as Easyptr does seem to have difficulty handling sprites by name. If the sprites are appended to a file and a command like SPRA used to refer to them by address or number all seems fine (thanks Thierry). I've passed this info on to the author of Easyptr in case it helps sort this out. Another tip came from Albin Hessler himself (author of Easyptr). As it happens, I had got this right, but it's worth passing on. When setting loose item justification, you need to think of where the sprite origin will be. If the default of centre justification is used for the loose item and the origin is top left, the origin is drawn at the centre of the loose item and so the sprite cannot fit unless the loose item is proportionately larger than the sprite. As it happens, if the sprite is assigned by name MITEM #channel%,loose_item,-2,'spritename' you always get either an out of range error or invisible sprite, so this didn't help. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html -Original Message- From: François Van Emelen [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 23 December 2001 23:15 Subject: Re: [ql-users] Easyptr 3 Hi You can use the name of sprites instead of their number if you gave them one in the application manager Easyspr (appman_obj). Once Lrespred, you can do something like this: 100 outln 120 mysprite=spra(xyw): rem the name of the sprite 140 wsprt 100,100,mysprite And you will see your xyw sprite on the screen. Does this help you? Francois Van Emelen Dilwyn Jones wrote: Thank you Thierry. I should have thought of directly addressing the sprite like this. So if I just APPEND the sprites to a ptrmen_cde file for example that should work fine compiled. It may also work in BASIC I suppose. Pity about the MITEM bug, it would have been nice to allow the user to specify and load a sprite as an icon for those who have the sprite editor and for me to release collections of sprites to go with this program (although I may be able to work around this by appending a dummy sprite as a buffer to load a sprite into for example. Still, thank you for the suggestion, which should save me a lot of work. Looking at the manual, SPRA should also allow the name of the sprite to be specified in place of number, but I guess this might be a little bit slower if it has to search for the name. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html There is a bug in MITEM that prevents it to load a sprite by its name (or filename). The workaround is to place the sprite into an appendix and to load it by its address with: MITEM #Channel,Item_number,-2,SPRA(Sprite_number) where sprite_number is the number of appearance in the appendix file (this appendix has to be linked to the QLiberated program). QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Fw: [ql-users] Easyptr 3
Earlier I wrote: Another tip came from Albin Hessler himself (author of Easyptr). As it happens, I had got this right, but it's worth passing on. When setting loose item justification, you need to think of where the sprite origin will be. If the default of centre justification is used for the loose item and the origin is top left, the origin is drawn at the centre of the loose item and so the sprite cannot fit unless the loose item is proportionately larger than the sprite. As it happens, if the sprite is assigned by name MITEM #channel%,loose_item,-2,'spritename' you always get either an out of range error or invisible sprite, so this didn't help. I slightly misunderstood this and got it wrong, as it's not this simple, sorry. I have just tried putting 32x24 sprites (linked to ptrmenr_cde resident, interpreted) into a loose item of the same size. The origin of the sprites is top left, this would only work if centre justified, not left justified sorry (I got this the wrong way round by misreading the author's suggestion). For those who like to probe such things: I appended 3 test sprites (a1_spr, a2_spr and a3_spr) to ptrmenr_cde then rebooted with this resident so the test program could find the sprites appended in memory rather than from disk to get around the name problem. PRINT SPRA(1),SPRA(2),SPRA(3) gave the correct addresses in memory. PRINT SPRA('a1'),SPRA('a2'),SPRA('a3') gave 'not found' error. I also tried SPRA(a1) SPRA(a1_spr) and SPRA('a1_spr') etc permuations to ensure I understood the naming conventions correctly. So, I am now convinced Thierry is right and Easyptr has problems coping with sprites referenced by name, but handles sprites referenced by address or number OK. I guess this has not really become apparent before due to the fact that you don't often want to assign sprites to loose items in interpreted programs very often, it's just that my program allows users to select preferred sprites for the icons in the program. OK, this won't mean a thing to those not conversant with Easyptr, QPTR etc, but it's as well to get these facts about our programming tools out in the open to be aired in case other QL programmers encounter the same problems. I just hope I can persuade the author to address this little problem with Easyptr (and upgrade it to better handle GD2 facilities perhaps!) -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Easyptr 3
Dilwyn Jones writes: OK, this won't mean a thing to those not conversant with Easyptr, QPTR etc, but it's as well to get these facts about our programming tools out in the open to be aired in case other QL programmers encounter the same problems. I just hope I can persuade the author to address this little problem with Easyptr (and upgrade it to better handle GD2 facilities perhaps!) An upgrade to Easyptr would be highly desirable and I for one would be more than happy to fork out some real dosh for it. Any one programming for PE, whether in S*Basic, C or assembler, should consider adding this great tool to their kit. Highly recommended! Merry Christmas, and all that! Per
[ql-users] Easyptr 3
Can anyone help me with an Easyptr query? I am trying to assign a sprite to be a loose item object within a BASIC program, with the MITEM command. It works fine if you put the sprite in the loose item from Easymenu, but the sprite needs to be changed from BASIC. Design a simple menu, call it test_men for example. Create just one loose item big enough to hold the sprite, which is called hand_spr. This will be loose item -1 Here's the simple program to set it up: 100 MDRAW #0,'flp1_test_men' 110 MITEM #0,-1,-2,'flp1_hand_spr','H' 120 num = MCALL(#0) 130 MCLEAR #0 Line 110 sets the object for loose item number -1 to be a sprite (item type -2 for the sprite as per page 2/123 of the manual), and 'H' is the selection key. The menu appears but the loose item is blank. Very occasionally you'll get a 'bad parameter' error or the sprite appears outside the loose item and the program crashes. If you substitute a text item with 110 MITEM #0,-1,0,'Hi','H' the program works as expected. This is driving me mad trying to resolve this and the facility is needed for a program I'm writing. Help! (Have tried to contact the author, no response yet though!) -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Easyptr 3
On Fri, 21 Dec 2001 08:38:40 -, Dilwyn Jones [EMAIL PROTECTED] wrote: Can anyone help me with an Easyptr query? I am trying to assign a sprite to be a loose item object within a BASIC program, with the MITEM command. It works fine if you put the sprite in the loose item from Easymenu, but the sprite needs to be changed from BASIC. There is a bug in MITEM that prevents it to load a sprite by its name (or filename). The workaround is to place the sprite into an appendix and to load it by its address with: MITEM #Channel,Item_number,-2,SPRA(Sprite_number) where sprite_number is the number of appearance in the appendix file (this appendix has to be linked to the QLiberated program). QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Easyptr 3
Thank you Thierry. I should have thought of directly addressing the sprite like this. So if I just APPEND the sprites to a ptrmen_cde file for example that should work fine compiled. It may also work in BASIC I suppose. Pity about the MITEM bug, it would have been nice to allow the user to specify and load a sprite as an icon for those who have the sprite editor and for me to release collections of sprites to go with this program (although I may be able to work around this by appending a dummy sprite as a buffer to load a sprite into for example. Still, thank you for the suggestion, which should save me a lot of work. Looking at the manual, SPRA should also allow the name of the sprite to be specified in place of number, but I guess this might be a little bit slower if it has to search for the name. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html There is a bug in MITEM that prevents it to load a sprite by its name (or filename). The workaround is to place the sprite into an appendix and to load it by its address with: MITEM #Channel,Item_number,-2,SPRA(Sprite_number) where sprite_number is the number of appearance in the appendix file (this appendix has to be linked to the QLiberated program). QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Easyptr 3
On Fri, 21 Dec 2001 12:40:26 -, Dilwyn Jones [EMAIL PROTECTED] wrote: Thank you Thierry. I should have thought of directly addressing the sprite like this. So if I just APPEND the sprites to a ptrmen_cde file for example that should work fine compiled. Correct. It may also work in BASIC I suppose. Yes, provided you LRESPR a ptrmen_cde copy merged with the appendix containing the sprite... .../... Looking at the manual, SPRA should also allow the name of the sprite to be specified in place of number, IIRC this does not work either: I think the bug is generic (i.e. you cannot reference a sprite by its name, whatever EasyMenu extension you use)... QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Easyptr 3
It may also work in BASIC I suppose. Yes, provided you LRESPR a ptrmen_cde copy merged with the appendix containing the sprite... Yes, that is what I meant. .../... Looking at the manual, SPRA should also allow the name of the sprite to be specified in place of number, IIRC this does not work either: I think the bug is generic (i.e. you cannot reference a sprite by its name, whatever EasyMenu extension you use)... Ah, I understand, this does explain the problems I had. Thank you again. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
RE: [ql-users] Easyptr
I seem to remember not being able to get the animated sprites to work under EasyPtr 3 myself on a JS QL. You might be having the same problem. Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Dilwyn Jones [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 7:31 PM To: QL Users List Subject: [ql-users] Easyptr Has anyone managed to get animated sprites in Easyptr 3 to work on QPC (QL 4 colour mode)? This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] Easyptr
Hello, Creating animated sprites isn't that difficult with Easyptr 3, but it seems that only the first definition of an animated sprite appears in a sprite used as info-object or loose-object. Animated sprites are alright (even in Prowess) to replace the pointer. As far as I know, only QD and Qspread use animated icons, but then they are not created with Easyptr 3, I think. François Van Emelen Dilwyn Jones wrote: Has anyone managed to get animated sprites in Easyptr 3 to work on QPC (QL 4 colour mode)? My QL is still packed away so I can't try it on a non-QPC system for comparison. I followed the demo in the manual (including right clicking on TIME for last frame) so should be certain I've set it up right; it just doesn't animate when the program is run! I notice that animated sprites in programs like QD work on QPC, so animation per se works, it's just that I can't (yet) get Easyptr ones to work. If someone can confirm the Easyptr ones actually work on QPC, I can then spend more time trying to fix any errors I may be making! -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Easyptr
François Van Emelen wrote: As far as I know, only QD and Qspread use animated icons, but then they are not created with Easyptr 3, I think. They do the animation themselves. The PE can only animate mouse pointers. Marcel
Re: [ql-users] Easyptr
Marcel Kilgus wrote: François Van Emelen wrote: As far as I know, only QD and Qspread use animated icons, but then they are not created with Easyptr 3, I think. They do the animation themselves. The PE can only animate mouse pointers. Thank you Marcel. Armed with that I got the animated Easyptr sprites working first time. So the instructions for creating an animated sprite in Easyptr are correct, but it is not too obvious that they can only be used as mouse pointers. I suppose it may be this way in case the pointer environment ever handles animated objects as well as mouse pointers (Easyptr can only do what PE can manage after all). As you say, only mouse pointers can be animated, loose item objects and info onjects using animated sprites only display the first frame of the animated sprite. It is still great fun to make a mouse pointer that changes colour all the time, for example! -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
[ql-users] Easyptr
Has anyone managed to get animated sprites in Easyptr 3 to work on QPC (QL 4 colour mode)? My QL is still packed away so I can't try it on a non-QPC system for comparison. I followed the demo in the manual (including right clicking on TIME for last frame) so should be certain I've set it up right; it just doesn't animate when the program is run! I notice that animated sprites in programs like QD work on QPC, so animation per se works, it's just that I can't (yet) get Easyptr ones to work. If someone can confirm the Easyptr ones actually work on QPC, I can then spend more time trying to fix any errors I may be making! -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html