Re: [Ql-Users] QPC2 v5.02
Hi, >>> Just to chime in, the newest SMSQmulator (hopefully) to come out in a >>> few days will do the same, i.e. treat NFA/SFA as win type. >> Hm, I've just seen that Qubide is also another type. How about we >> simply define our NFS/DOS devices as type "4" for "emulated" or >> something? This should solve the QD problem, too. >> Sounds good to me. That way, no need to change SMSQE I'll just update the info > Good idea! But please, whatever you do, do it the same way for the same > thing! :o) > > (Sorry for butting in here..) That's the whole point of having this discussion here! Anyway, the more the merrier. Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
On 01/12/2021 18:08, Marcel Kilgus via Ql-Users wrote: Wolfgang Lenerz via Ql-Users wrote: Hi, Just to chime in, the newest SMSQmulator (hopefully) to come out in a few days will do the same, i.e. treat NFA/SFA as win type. Hm, I've just seen that Qubide is also another type. How about we simply define our NFS/DOS devices as type "4" for "emulated" or something? This should solve the QD problem, too. Marcel Good idea! But please, whatever you do, do it the same way for the same thing! :o) (Sorry for butting in here..) Per ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Wolfgang Lenerz via Ql-Users wrote: > Hi, > Just to chime in, the newest SMSQmulator (hopefully) to come out in a > few days will do the same, i.e. treat NFA/SFA as win type. Hm, I've just seen that Qubide is also another type. How about we simply define our NFS/DOS devices as type "4" for "emulated" or something? This should solve the QD problem, too. Marcel ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
66 / 5000
Risultati della traduzione
Sorry for the delay in my reply .. yes, it seems like a great idea
Il giorno mar 30 nov 2021 alle ore 13:34 Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> ha scritto:
> Hi,
>
> Just to chime in, the newest SMSQmulator (hopefully) to come out in a
> few days will do the same, i.e. treat NFA/SFA as win type.
>
>
> There is a reason for (at least for me):
>
> I use QD extensively.
> When QD saves data to a file, it first of all checks the device type via
> iof.xinf. If it detects that the drive is registered as a an msdos type
> device, it saves the file with line ending CR+LF, instead of the normal
> LF as used on win devices.
>
> If you now try to use the MacroAssembler to assemble a file that
> contains macros, this will fail (the MA seems to calculate the number of
> bytes it has got, which will be wrong as the NFA driver converts CF+LF
> to LF automagically) The MA then resets the file position to somewhere
> in the file, corresponding to the number of bytes before the macro (I
> suppose to read th emacro again) and that will be wrong, so that it
> reads something other in the file and then fails.
>
>
> That being said, might I make a suggestion?
>
> Giorgio said:
>
> The old behavior was that DMEDIUM_DRIVE returned -1 when pointing
> to a dos disk. it was not "correct" but it allowed me to distinguish
> the two
> >>> types.
>
> Indeed, that's not the right way, one should use the DMEDIUM_TYPE
> function for that (returns 1 - qdos, 2 - msdos etc) - but this won't
> help you, as that now returns "qdos" device type for dos and nfa/sfa.
>
> However, the specifications also provide for a device sub-type, which is
> not returned by any function and which, AFAIK is not used. One might
> possibly use that to return 1 or 2 as sub-type also.
>
> I'd be willing to create the new basic keyword for that in SMSQE
> ("DMEDIUM_STYPE").
>
> Would that be agreeable to all?
>
>
> Have fun!
>
> Wolfgang
>
>
>
> what do i need it for?
> I use it in a couple of programs .. in particular the new file manager
> >>> that
> I have created and which I think I will be able to publish in a few
> weeks. Obviously
> it works the same but in front of each device he placed an icon to be
> >>> able
> to identify it if cd / ram / win / dos It would be interesting to be
> able
> to distinguish all the types but obviously I have no idea of the work
> >>> this
> entails. Mine is not a criticism, I'm just chatting.
>
> Giorgio
>
> Il giorno ven 26 nov 2021 alle ore 10:09 Marcel Kilgus via Ql-Users <
> ql-users@lists.q-v-d.com> ha scritto:
>
> > Giorgio Garabello via Ql-Users wrote:
> >>> I uploaded a small bugfix release QPC2v5.02.
> >>>
> >>> Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2
> >> I have a doubt, how can I now recognize a DOS disk from a WIN one?
> > It has been this way for 20 years, I just reverted it back to the
> > old behavior.
> >
> > Why would you want to recognize a DOS disk from a WIN one?
> >
> > Marcel
> >
> > ___
> > QL-Users Mailing List
> >
> ___
> QL-Users Mailing List
> .
> >>> ___
> >>> QL-Users Mailing List
> >>>
> >> ___
> >> QL-Users Mailing List
> >>
> > ___
> > QL-Users Mailing List
> >
> ___
> QL-Users Mailing List
___
QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Op 30/11/2021 om 21:14 schreef Wolfgang Lenerz via Ql-Users:
Hi François,
This will be fixed.
Have fun!
Wolfgang
Op 30/11/2021 om 13:34 schreef Wolfgang Lenerz via Ql-Users:
Hi,
Just to chime in, the newest SMSQmulator (hopefully) to come out in a
few days will do the same, i.e. treat NFA/SFA as win type.
There is a reason for (at least for me):
I use QD extensively.
When QD saves data to a file, it first of all checks the device type via
iof.xinf. If it detects that the drive is registered as a an msdos type
device, it saves the file with line ending CR+LF, instead of the normal
LF as used on win devices.
If you now try to use the MacroAssembler to assemble a file that
contains macros, this will fail (the MA seems to calculate the number of
bytes it has got, which will be wrong as the NFA driver converts CF+LF
to LF automagically) The MA then resets the file position to somewhere
in the file, corresponding to the number of bytes before the macro (I
suppose to read th emacro again) and that will be wrong, so that it
reads something other in the file and then fails.
That being said, might I make a suggestion?
Giorgio said:
The old behavior was that DMEDIUM_DRIVE returned -1 when pointing
to a dos disk. it was not "correct" but it allowed me to
distinguish the two
types.
Indeed, that's not the right way, one should use the DMEDIUM_TYPE
function for that (returns 1 - qdos, 2 - msdos etc) - but this won't
help you, as that now returns "qdos" device type for dos and nfa/sfa.
However, the specifications also provide for a device sub-type, which is
not returned by any function and which, AFAIK is not used. One might
possibly use that to return 1 or 2 as sub-type also.
I'd be willing to create the new basic keyword for that in SMSQE
("DMEDIUM_STYPE").
Would that be agreeable to all?
Have fun!
Wolfgang
Hi Wolfgang,
While working on the next version of SMSQmulator could you verify if
LBYTES works correctly on your system?
LBYTES Filename_scr,SCR_SCR_BASE seems to lock SMSQmulator: SO TAKE CARE
100 WINDOW SCR_XLIM,SCR_YLIM,0,0
105 REMark
110 REMark OPEN_IN#3,dev1_bckgrnd_wallpaper_def:INPUT#3,p$:CLOSE#3
115 PAPER 6:CLS: REMark instead of WL_BMP8LOAD p$ for testing
120 :
125 SBYTES_O dev1_dump_scr,SCR_BASE,SCR_LLEN*SCR_YLIM
130 :
135 REMark dev1_dump_scr can be displayed correctly in QPC2
140 REMark with LBYTES dev1_dump_scr,scr_base
145 :
150 REMark but locks SMSQmulator
155 REMark dump_scr is 4147200 long
160 REMark Screen size 1920x1080
165 REMark window mode fullscreen
Thanks
François Van Emelen
___
QL-Users Mailing List
___
QL-Users Mailing List
thank you
François Van Emelen
___
QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Hi François,
This will be fixed.
Have fun!
Wolfgang
> Op 30/11/2021 om 13:34 schreef Wolfgang Lenerz via Ql-Users:
>> Hi,
>>
>> Just to chime in, the newest SMSQmulator (hopefully) to come out in a
>> few days will do the same, i.e. treat NFA/SFA as win type.
>>
>>
>> There is a reason for (at least for me):
>>
>> I use QD extensively.
>> When QD saves data to a file, it first of all checks the device type via
>> iof.xinf. If it detects that the drive is registered as a an msdos type
>> device, it saves the file with line ending CR+LF, instead of the normal
>> LF as used on win devices.
>>
>> If you now try to use the MacroAssembler to assemble a file that
>> contains macros, this will fail (the MA seems to calculate the number of
>> bytes it has got, which will be wrong as the NFA driver converts CF+LF
>> to LF automagically) The MA then resets the file position to somewhere
>> in the file, corresponding to the number of bytes before the macro (I
>> suppose to read th emacro again) and that will be wrong, so that it
>> reads something other in the file and then fails.
>>
>>
>> That being said, might I make a suggestion?
>>
>> Giorgio said:
>>
>> The old behavior was that DMEDIUM_DRIVE returned -1 when pointing
>> to a dos disk. it was not "correct" but it allowed me to
>> distinguish the two
> types.
>> Indeed, that's not the right way, one should use the DMEDIUM_TYPE
>> function for that (returns 1 - qdos, 2 - msdos etc) - but this won't
>> help you, as that now returns "qdos" device type for dos and nfa/sfa.
>>
>> However, the specifications also provide for a device sub-type, which is
>> not returned by any function and which, AFAIK is not used. One might
>> possibly use that to return 1 or 2 as sub-type also.
>>
>> I'd be willing to create the new basic keyword for that in SMSQE
>> ("DMEDIUM_STYPE").
>>
>> Would that be agreeable to all?
>>
>>
>> Have fun!
>>
>> Wolfgang
>>
>>
>
>
> Hi Wolfgang,
>
> While working on the next version of SMSQmulator could you verify if
> LBYTES works correctly on your system?
>
> LBYTES Filename_scr,SCR_SCR_BASE seems to lock SMSQmulator: SO TAKE CARE
>
> 100 WINDOW SCR_XLIM,SCR_YLIM,0,0
> 105 REMark
> 110 REMark OPEN_IN#3,dev1_bckgrnd_wallpaper_def:INPUT#3,p$:CLOSE#3
> 115 PAPER 6:CLS: REMark instead of WL_BMP8LOAD p$ for testing
> 120 :
> 125 SBYTES_O dev1_dump_scr,SCR_BASE,SCR_LLEN*SCR_YLIM
> 130 :
> 135 REMark dev1_dump_scr can be displayed correctly in QPC2
> 140 REMark with LBYTES dev1_dump_scr,scr_base
> 145 :
> 150 REMark but locks SMSQmulator
> 155 REMark dump_scr is 4147200 long
> 160 REMark Screen size 1920x1080
> 165 REMark window mode fullscreen
>
> Thanks
>
> François Van Emelen
>
> ___
> QL-Users Mailing List
___
QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Op 30/11/2021 om 13:34 schreef Wolfgang Lenerz via Ql-Users:
Hi,
Just to chime in, the newest SMSQmulator (hopefully) to come out in a
few days will do the same, i.e. treat NFA/SFA as win type.
There is a reason for (at least for me):
I use QD extensively.
When QD saves data to a file, it first of all checks the device type via
iof.xinf. If it detects that the drive is registered as a an msdos type
device, it saves the file with line ending CR+LF, instead of the normal
LF as used on win devices.
If you now try to use the MacroAssembler to assemble a file that
contains macros, this will fail (the MA seems to calculate the number of
bytes it has got, which will be wrong as the NFA driver converts CF+LF
to LF automagically) The MA then resets the file position to somewhere
in the file, corresponding to the number of bytes before the macro (I
suppose to read th emacro again) and that will be wrong, so that it
reads something other in the file and then fails.
That being said, might I make a suggestion?
Giorgio said:
The old behavior was that DMEDIUM_DRIVE returned -1 when pointing
to a dos disk. it was not "correct" but it allowed me to distinguish the two
types.
Indeed, that's not the right way, one should use the DMEDIUM_TYPE
function for that (returns 1 - qdos, 2 - msdos etc) - but this won't
help you, as that now returns "qdos" device type for dos and nfa/sfa.
However, the specifications also provide for a device sub-type, which is
not returned by any function and which, AFAIK is not used. One might
possibly use that to return 1 or 2 as sub-type also.
I'd be willing to create the new basic keyword for that in SMSQE
("DMEDIUM_STYPE").
Would that be agreeable to all?
Have fun!
Wolfgang
Hi Wolfgang,
While working on the next version of SMSQmulator could you verify if
LBYTES works correctly on your system?
LBYTES Filename_scr,SCR_SCR_BASE seems to lock SMSQmulator: SO TAKE CARE
100 WINDOW SCR_XLIM,SCR_YLIM,0,0
105 REMark
110 REMark OPEN_IN#3,dev1_bckgrnd_wallpaper_def:INPUT#3,p$:CLOSE#3
115 PAPER 6:CLS: REMark instead of WL_BMP8LOAD p$ for testing
120 :
125 SBYTES_O dev1_dump_scr,SCR_BASE,SCR_LLEN*SCR_YLIM
130 :
135 REMark dev1_dump_scr can be displayed correctly in QPC2
140 REMark with LBYTES dev1_dump_scr,scr_base
145 :
150 REMark but locks SMSQmulator
155 REMark dump_scr is 4147200 long
160 REMark Screen size 1920x1080
165 REMark window mode fullscreen
Thanks
François Van Emelen
___
QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Hi,
Just to chime in, the newest SMSQmulator (hopefully) to come out in a
few days will do the same, i.e. treat NFA/SFA as win type.
There is a reason for (at least for me):
I use QD extensively.
When QD saves data to a file, it first of all checks the device type via
iof.xinf. If it detects that the drive is registered as a an msdos type
device, it saves the file with line ending CR+LF, instead of the normal
LF as used on win devices.
If you now try to use the MacroAssembler to assemble a file that
contains macros, this will fail (the MA seems to calculate the number of
bytes it has got, which will be wrong as the NFA driver converts CF+LF
to LF automagically) The MA then resets the file position to somewhere
in the file, corresponding to the number of bytes before the macro (I
suppose to read th emacro again) and that will be wrong, so that it
reads something other in the file and then fails.
That being said, might I make a suggestion?
Giorgio said:
The old behavior was that DMEDIUM_DRIVE returned -1 when pointing
to a dos disk. it was not "correct" but it allowed me to distinguish the
two
>>> types.
Indeed, that's not the right way, one should use the DMEDIUM_TYPE
function for that (returns 1 - qdos, 2 - msdos etc) - but this won't
help you, as that now returns "qdos" device type for dos and nfa/sfa.
However, the specifications also provide for a device sub-type, which is
not returned by any function and which, AFAIK is not used. One might
possibly use that to return 1 or 2 as sub-type also.
I'd be willing to create the new basic keyword for that in SMSQE
("DMEDIUM_STYPE").
Would that be agreeable to all?
Have fun!
Wolfgang
what do i need it for?
I use it in a couple of programs .. in particular the new file manager
>>> that
I have created and which I think I will be able to publish in a few
weeks. Obviously
it works the same but in front of each device he placed an icon to be
>>> able
to identify it if cd / ram / win / dos It would be interesting to be
able
to distinguish all the types but obviously I have no idea of the work
>>> this
entails. Mine is not a criticism, I'm just chatting.
Giorgio
Il giorno ven 26 nov 2021 alle ore 10:09 Marcel Kilgus via Ql-Users <
ql-users@lists.q-v-d.com> ha scritto:
> Giorgio Garabello via Ql-Users wrote:
>>> I uploaded a small bugfix release QPC2v5.02.
>>>
>>> Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2
>> I have a doubt, how can I now recognize a DOS disk from a WIN one?
> It has been this way for 20 years, I just reverted it back to the
> old behavior.
>
> Why would you want to recognize a DOS disk from a WIN one?
>
> Marcel
>
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List
.
>>> ___
>>> QL-Users Mailing List
>>>
>> ___
>> QL-Users Mailing List
>>
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
My DevGet subroutine (www.Knoware.no/htm/basic.htm) demonstrates how you can always get the real device name. Per On 26/11/2021 10:59, Giorgio Garabello via Ql-Users wrote: It is not a safe method, it can be renamed from DOS_USE Giorgio Il giorno ven 26 nov 2021 alle ore 10:49 pjwitte via Ql-Users < ql-users@lists.q-v-d.com> ha scritto: Giorgio, Use the device name to make the distinction: If its called DOS, then its DOS, etc. Per On 26/11/2021 10:28, Giorgio Garabello via Ql-Users wrote: The old behavior was that DMEDIUM_DRIVE returned -1 when pointing to a dos disk. it was not "correct" but it allowed me to distinguish the two types. what do i need it for? I use it in a couple of programs .. in particular the new file manager that I have created and which I think I will be able to publish in a few weeks. Obviously it works the same but in front of each device he placed an icon to be able to identify it if cd / ram / win / dos It would be interesting to be able to distinguish all the types but obviously I have no idea of the work this entails. Mine is not a criticism, I'm just chatting. Giorgio Il giorno ven 26 nov 2021 alle ore 10:09 Marcel Kilgus via Ql-Users < ql-users@lists.q-v-d.com> ha scritto: Giorgio Garabello via Ql-Users wrote: I uploaded a small bugfix release QPC2v5.02. Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 I have a doubt, how can I now recognize a DOS disk from a WIN one? It has been this way for 20 years, I just reverted it back to the old behavior. Why would you want to recognize a DOS disk from a WIN one? Marcel ___ QL-Users Mailing List ___ QL-Users Mailing List . ___ QL-Users Mailing List ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
It is not a safe method, it can be renamed from DOS_USE Giorgio Il giorno ven 26 nov 2021 alle ore 10:49 pjwitte via Ql-Users < ql-users@lists.q-v-d.com> ha scritto: > Giorgio, > > Use the device name to make the distinction: If its called DOS, then > its DOS, etc. > Per > > On 26/11/2021 10:28, Giorgio Garabello via Ql-Users wrote: > > The old behavior was that DMEDIUM_DRIVE returned -1 when pointing to a > dos > > disk. it was not "correct" but it allowed me to distinguish the two > types. > > what do i need it for? > > I use it in a couple of programs .. in particular the new file manager > that > > I have created and which I think I will be able to publish in a few > > weeks. Obviously > > it works the same but in front of each device he placed an icon to be > able > > to identify it if cd / ram / win / dos It would be interesting to be able > > to distinguish all the types but obviously I have no idea of the work > this > > entails. Mine is not a criticism, I'm just chatting. > > > > Giorgio > > > > Il giorno ven 26 nov 2021 alle ore 10:09 Marcel Kilgus via Ql-Users < > > ql-users@lists.q-v-d.com> ha scritto: > > > >> Giorgio Garabello via Ql-Users wrote: > I uploaded a small bugfix release QPC2v5.02. > > Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 > >>> I have a doubt, how can I now recognize a DOS disk from a WIN one? > >> It has been this way for 20 years, I just reverted it back to the > >> old behavior. > >> > >> Why would you want to recognize a DOS disk from a WIN one? > >> > >> Marcel > >> > >> ___ > >> QL-Users Mailing List > >> > > ___ > > QL-Users Mailing List > > . > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Giorgio, Use the device name to make the distinction: If its called DOS, then its DOS, etc. Per On 26/11/2021 10:28, Giorgio Garabello via Ql-Users wrote: The old behavior was that DMEDIUM_DRIVE returned -1 when pointing to a dos disk. it was not "correct" but it allowed me to distinguish the two types. what do i need it for? I use it in a couple of programs .. in particular the new file manager that I have created and which I think I will be able to publish in a few weeks. Obviously it works the same but in front of each device he placed an icon to be able to identify it if cd / ram / win / dos It would be interesting to be able to distinguish all the types but obviously I have no idea of the work this entails. Mine is not a criticism, I'm just chatting. Giorgio Il giorno ven 26 nov 2021 alle ore 10:09 Marcel Kilgus via Ql-Users < ql-users@lists.q-v-d.com> ha scritto: Giorgio Garabello via Ql-Users wrote: I uploaded a small bugfix release QPC2v5.02. Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 I have a doubt, how can I now recognize a DOS disk from a WIN one? It has been this way for 20 years, I just reverted it back to the old behavior. Why would you want to recognize a DOS disk from a WIN one? Marcel ___ QL-Users Mailing List ___ QL-Users Mailing List . ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
The old behavior was that DMEDIUM_DRIVE returned -1 when pointing to a dos disk. it was not "correct" but it allowed me to distinguish the two types. what do i need it for? I use it in a couple of programs .. in particular the new file manager that I have created and which I think I will be able to publish in a few weeks. Obviously it works the same but in front of each device he placed an icon to be able to identify it if cd / ram / win / dos It would be interesting to be able to distinguish all the types but obviously I have no idea of the work this entails. Mine is not a criticism, I'm just chatting. Giorgio Il giorno ven 26 nov 2021 alle ore 10:09 Marcel Kilgus via Ql-Users < ql-users@lists.q-v-d.com> ha scritto: > Giorgio Garabello via Ql-Users wrote: > >> I uploaded a small bugfix release QPC2v5.02. > >> > >> Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 > > I have a doubt, how can I now recognize a DOS disk from a WIN one? > > It has been this way for 20 years, I just reverted it back to the > old behavior. > > Why would you want to recognize a DOS disk from a WIN one? > > Marcel > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Giorgio Garabello via Ql-Users wrote: >> I uploaded a small bugfix release QPC2v5.02. >> >> Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 > I have a doubt, how can I now recognize a DOS disk from a WIN one? It has been this way for 20 years, I just reverted it back to the old behavior. Why would you want to recognize a DOS disk from a WIN one? Marcel ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Il giorno gio 25 nov 2021 alle ore 18:40 Marcel Kilgus via Ql-Users < ql-users@lists.q-v-d.com> ha scritto: > I uploaded a small bugfix release QPC2v5.02. > > Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 I have a doubt, how can I now recognize a DOS disk from a WIN one? Giorgio ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 v5.02
Thank You Ever so Much Marcel for the Update of QPC2 Thanks Again Simon Foster On Thursday, 25 November 2021, 17:40:21 GMT, Marcel Kilgus via Ql-Users wrote: I uploaded a small bugfix release QPC2v5.02. Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 (MS-DOS) because QD switches to different line endings on MS-DOS drives and that confuses other applications. Also fixed direct SBYTES to screen from WIN/FLP/DOS devices. https://www.kilgus.net/qpc/downloads/ Enjoy, Marcel ___ QL-Users Mailing List ___ QL-Users Mailing List
[Ql-Users] QPC2 v5.02
I uploaded a small bugfix release QPC2v5.02. Switch DMEDIUM_FORMAT for the DOS device to 1 (QDOS) instead of 2 (MS-DOS) because QD switches to different line endings on MS-DOS drives and that confuses other applications. Also fixed direct SBYTES to screen from WIN/FLP/DOS devices. https://www.kilgus.net/qpc/downloads/ Enjoy, Marcel ___ QL-Users Mailing List
