OpenEuphoria

2. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 26, 2006
• 662 views

Pete Stoner wrote:
> 
> I have an include file doing a dll call, the first call is done to get the
> buffer
> size required. Using the translator I was intermittantly getting '87' returned
> which is ERROR_INVALID_PARAMETER instead of the expected '111'
> (ERROR_BUFFER_OVERFLOW).
> The first odd thing was that it would fail when called from my main prog but
> would work if I used the include file on its own with the call tagged on the
> end.. 
> 
> Anyway to cut a long story of fiddling around short, I've cut things down as
> much as I can for now and I can recreate the failure, which I can 'fix' by a
> slight change in any of the include files i.e. removing a single character
> from
> a (now unused) variable name or even just removing one blank line!!
> 
> Its very reliable - run cutdown program and get '87' returned, delete blank
> line from file and get the expected '111' returned!! If I bind the version
> that
> fails it then runs ok - probably because of the binder deleting unused
> routines
> etc.
> 
> I'm lost here, if someone else would like to try this to see if they get the
> same results please let me know... As it seems so specific to number of
> lines/characters
> I will have to send you a zip of the include files used (only win32lib, my dll
> include file and whats left of my main prog).
> 
> PeteS

Pete,

Are you using Eu 2.5 or 2.5t3? If your using 2.5t3, does it fail with 2.5?


Regards,
Vincent

4. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Pete Stoner <stoner.pete at gmail.com> Feb 26, 2006
• 829 views

Pete Stoner wrote:
> 
> I have an include file doing a dll call, the first call is done to get the
> buffer
> size required. Using the translator I was intermittantly getting '87' returned
> which is ERROR_INVALID_PARAMETER instead of the expected '111'
> (ERROR_BUFFER_OVERFLOW).
> The first odd thing was that it would fail when called from my main prog but
> would work if I used the include file on its own with the call tagged on the
> end.. 
> 
> Anyway to cut a long story of fiddling around short, I've cut things down as
> much as I can for now and I can recreate the failure, which I can 'fix' by a
> slight change in any of the include files i.e. removing a single character
> from
> a (now unused) variable name or even just removing one blank line!!
> 
> Its very reliable - run cutdown program and get '87' returned, delete blank
> line from file and get the expected '111' returned!! If I bind the version
> that
> fails it then runs ok - probably because of the binder deleting unused
> routines
> etc.

> 
> PeteS


OK after a lot of trial and error, using registered 2.5 and Win32lib 60.6 and
using this chopped down include file.
file name - XGetAdaptersAddresses.ew

without warning
include w32support.e -- from Win32Lib v0.60.6

global constant
	ADAPTER_TYPE			=1,
    ADAPTER_NAME			=2,
    ADAPTER_FRIENDLYNAME	=3,
    ADAPTER_DESCRIPTION		=4,
    ADAPTER_MAC_ADDRESS		=5,
    ADAPTER_STATUS			=6,
    DHCP_ENABLED			=7,
    DYNAMIC_DNS				=8


constant iphlpapi = open_dll( "iphlpapi.dll" )	
   			
constant xGetAdaptersAddresses = define_c_func( iphlpapi,
"GetAdaptersAddresses",
  		{C_ULONG, C_ULONG, C_POINTER, C_POINTER, C_ULONG}, 	
  		C_INT)

constant AF_INET		= 2		
constant AF_INET6		= 23	
constant AF_UNSPEC		= 0		
                                                                 

-- flags returned
constant 
 IP_ADAPTER_DDNS_ENABLED               = #0001, 
 IP_ADAPTER_REGISTER_ADAPTER_SUFFIX    = #0002, 
 IP_ADAPTER_DHCP_ENABLED               = #0004, 
 IP_ADAPTER_RECEIVE_ONLY               = #0008, 
 IP_ADAPTER_NO_MULTICAST               = #0010, 
 IP_ADAPTER_IPV6_OTHER_STATEFUL_CONFIG = #0020  

constant -- possible return values
  ERROR_SUCCESS			  = 0,  	
  ERROR_BUFFER_OVERFLOW   = 111, 	
									   	
  ERROR_INVALID_PARAMETER = 87, 	
									
									
  ERROR_NO_DATA           = 232, 	
  ERROR_NOT_SUPPORTED     = 50 		
-- adapter type constants
global constant
  IF_TYPE_OTHER     = 1,
  IF_TYPE_ETHERNET  = 6,
  IF_TYPE_TOKENRING = 9,
  IF_TYPE_FDDI      = 15,
  IF_TYPE_PPP       = 23,
  IF_TYPE_LOOPBACK  = 24,
  IF_TYPE_SLIP      = 28

global function GetAdaptersAddresses()
  atom struct, pOutBufLen, dwStatus, ptr, mac_len, flags, adapterInfo
  integer IF_type, operStatusret,  dhcp, dDNS
  sequence AdapterName, FriendlyName, Description, macAddr, interface_type,
			operStatus 
  atom num
  object data
  data = {}
   
   struct = allocate(4)
   pOutBufLen = allocate(4)
   poke4( pOutBufLen, 4 )  -- poke the wrong size for first call   
dwStatus = c_func( xGetAdaptersAddresses, {0, 0, NULL, struct, pOutBufLen} )
    if dwStatus != ERROR_BUFFER_OVERFLOW then 
    	data = dwStatus
    else
		data = {}
	end if
		free(struct)
		free(pOutBufLen)
    return data

end function


     object res

and calling it from 
file name - getAdaptersAddresse.exw

without warning
without trace
include Win32lib.ew            
include XGetAdaptersAddresses.ew
    
? GetAdaptersAddresses()
? GetAdaptersAddresses()
? GetAdaptersAddresses()

? 1/0

NOTE:- the file names are important.... I get the 87 (the error) on the first
call and a sequence (good return) on the second 2 calls. if I rename the calling
file to 'getAdaptersAddresses.exw' (one extra character) I get good returns from
all 3 calls.. If I then delete the 'object res' at the end of the include file,
the first call fails whatever the file name. The results of this changes as I
delete more of the unused lines...
The xGetAdaptersAddresses() is Windows XP only, earlier versions should return
'50' instead of '111', but it would be interesting to confirm you don't get the
'87' error..

I also tried the above with registered 2.4.. I could get a similar effect but
with different number of lines/characters deleted. The above combinations that
fail on 2.5 work on 2.4... Am I going crazy?

PeteS

6. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Bernie Ryan <xotron at bluefrog.com> Feb 26, 2006
• 669 views

Pete:

    Let us see the formal "C" discripton of GetAdaptersAddresses()
    function.

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

8. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Bernie Ryan <xotron at bluefrog.com> Feb 26, 2006
• 675 views

Pete Stoner wrote:
> 
> Bernie Ryan wrote:
> > 
> > 
> > Pete:
> > 
> >     Let us see the formal "C" discripton of GetAdaptersAddresses()
> >     function.
> > 
> > Bernie
> > 
> Hi Bernie, you can find the full details here..
> <a
> href="http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersaddresses.asp">http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersaddresses.asp</a>

Pete:

First the structure has to have 64 bit alignment as shown below.
This maybe why changing the program size may be Euphoria moving the
structure memory alignment around.

typedef struct _IP_ADAPTER_ADDRESSES {
  union {
    ULONGLONG Alignment;
    struct {
      ULONG Length;
      DWORD IfIndex;
    };
  };

Also did you see this note in the example to be sure your buffer length
is correct.

// Make an initial call to GetAdaptersAddresses to get the 
// size needed into the outBufLen variable

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
// Make an initial call to GetAdaptersAddresses to get the 
// size needed into the outBufLen variable

10. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by jacques deschênes <desja at globetrotter.net> Feb 27, 2006
• 705 views

Hi Pete,
I ran the following code on my machine without any problem, wathever the name 
I give to the file (using exwc.exe).
NOTE: it doesn't use win32lib

without warning
--include w32support.e -- from Win32Lib v0.60.6
include dll.e
include machine.e

global constant
    ADAPTER_TYPE=1,
    ADAPTER_NAME=2,
    ADAPTER_FRIENDLYNAME=3,
    ADAPTER_DESCRIPTION=4,
    ADAPTER_MAC_ADDRESS=5,
    ADAPTER_STATUS=6,
    DHCP_ENABLED=7,
    DYNAMIC_DNS=8


constant iphlpapi = open_dll( "iphlpapi.dll" )

constant xGetAdaptersAddresses = define_c_func( iphlpapi,
"GetAdaptersAddresses",
{C_ULONG, C_ULONG, C_POINTER,
                                                C_POINTER, C_ULONG},C_INT)

constant AF_INET= 2
constant AF_INET6= 23
constant AF_UNSPEC= 0
                                                                 

-- flags returned
constant 
 IP_ADAPTER_DDNS_ENABLED               = #0001, 
 IP_ADAPTER_REGISTER_ADAPTER_SUFFIX    = #0002, 
 IP_ADAPTER_DHCP_ENABLED               = #0004, 
 IP_ADAPTER_RECEIVE_ONLY               = #0008, 
 IP_ADAPTER_NO_MULTICAST               = #0010, 
 IP_ADAPTER_IPV6_OTHER_STATEFUL_CONFIG = #0020  

constant -- possible return values
  ERROR_SUCCESS = 0,
  ERROR_BUFFER_OVERFLOW   = 111,
  ERROR_INVALID_PARAMETER = 87, 
  ERROR_NO_DATA           = 232,
  ERROR_NOT_SUPPORTED     = 50
-- adapter type constants
global constant
  IF_TYPE_OTHER     = 1,
  IF_TYPE_ETHERNET  = 6,
  IF_TYPE_TOKENRING = 9,
  IF_TYPE_FDDI      = 15,
  IF_TYPE_PPP       = 23,
  IF_TYPE_LOOPBACK  = 24,
  IF_TYPE_SLIP      = 28

function GetAdapterFriendlyName(atom pName)
sequence name
integer i,wc
 name = ""
 wc = peek(pName) + peek(pName+1)*256
 i = 0
 while wc do
   name &= wc
   i += 2
   wc = peek(pName+i) + peek(pName+i+1)*256
 end while
 return name
end function

function GetAdapterDescription(atom pDescription)
sequence description
integer i,wc
  
  description = {}
  i = 0
  wc = peek(pDescription)+peek(pDescription+1)*256 -- wide char
  while wc do
    description &= wc
    i+= 2
    wc = peek(pDescription+i)+peek(pDescription+i+1)*256
  end while
  return description
end function

global function GetAdaptersAddresses()
  atom struct, pOutBufLen, dwStatus, ptr, mac_len, flags, adapterInfo
  integer IF_type, operStatusret,  dhcp, dDNS
sequence AdapterName, FriendlyName, Description, macAddr,
  interface_type,operStatus
  atom num,pAdapterName, pDescription, pNext
  object data
  data = {}
   
   struct = allocate(78)
   pOutBufLen = allocate(4)
   poke4( pOutBufLen,4 )  -- poke the wrong size for first call   
   dwStatus = c_func( xGetAdaptersAddresses, {0, 0, NULL, struct, pOutBufLen} ) 
   if dwStatus != ERROR_BUFFER_OVERFLOW then 
      data = dwStatus
   else
      free(struct)
      struct = allocate(peek4u(pOutBufLen))
      mem_set(struct,0,peek4u(pOutBufLen))
      dwStatus = c_func(xGetAdaptersAddresses,{0,0,NULL,struct,pOutBufLen})
      if dwStatus = ERROR_SUCCESS then
        pNext = struct
        data = {}
        while pNext do
data &=
          {{GetAdapterFriendlyName(peek4u(pNext+40)),GetAdapterDescription(peek4u(pNext+36))}}
          pNext = peek4u(pNext+8)
        end while   
      else
        data = dwStatus
      end if
   end if
   free(struct)
   free(pOutBufLen)
   return data
end function

object data    
data = GetAdaptersAddresses()
if sequence(data) then
 for i = 1 to length(data) do
   printf(1,"name: %s, description: %s\n",data[i])
 end for
end if

regards,
jacques Deschênes

12. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Pete Stoner <stoner.pete at gmail.com> Feb 28, 2006
• 674 views

jacques deschênes wrote:
> 
> 
> Hi Pete,
> I ran the following code on my machine without any problem, wathever the name
> 
> I give to the file (using exwc.exe).
> NOTE: it doesn't use win32lib
> 
> snipped
> 
> regards,
> jacques Deschênes

Jacques, I've done some more testing and still couldn't get your version to
fail, so I extended it to return all the fields I had in my win32lib version and
a few other minor changes as below...

without warning
 include dll.e
 include machine.e

global constant
   ADAPTER_TYPE=1,
   ADAPTER_NAME=2,
   ADAPTER_FRIENDLYNAME=3,
   ADAPTER_DESCRIPTION=4,
   ADAPTER_MAC_ADDRESS=5,
   ADAPTER_STATUS=6,
   DHCP_ENABLED=7,
   DYNAMIC_DNS=8,
   DNS_SUFFIX=9


constant iphlpapi = open_dll( "iphlpapi.dll" )

constant xGetAdaptersAddresses = define_c_func( iphlpapi,
"GetAdaptersAddresses",
  	{C_ULONG, 	-- Family, see constants below
  	C_ULONG, 	-- Flags ([in] Type of addresses to retrieve, see constants below
C_POINTER,	-- Reserved [in] The calling application should pass NULL for this
  parameter.
C_POINTER, 	-- [out] Pointer to a buffer. On successful return, this buffer
  contains the address information.
C_ULONG}, 	-- pOutBufLen [in, out] Pointer to a variable that specifies the
  size of the buffer pointed to by pAdapterAddresses.
  	C_INT)		-- return code

-- FAMILY
constant AF_INET= 2
constant AF_INET6= 23
constant AF_UNSPEC= 0


-- flags returned
constant
 IP_ADAPTER_DDNS_ENABLED               = #0001,
 IP_ADAPTER_REGISTER_ADAPTER_SUFFIX    = #0002,
 IP_ADAPTER_DHCP_ENABLED               = #0004,
 IP_ADAPTER_RECEIVE_ONLY               = #0008,
 IP_ADAPTER_NO_MULTICAST               = #0010,
 IP_ADAPTER_IPV6_OTHER_STATEFUL_CONFIG = #0020

constant -- possible return values
 ERROR_SUCCESS = 0,
 ERROR_BUFFER_OVERFLOW   = 111,
 ERROR_INVALID_PARAMETER = 87,
 ERROR_NO_DATA           = 232,
 ERROR_NOT_SUPPORTED     = 50
 
-- adapter type constants
global constant
 IF_TYPE_OTHER     = 1,
 IF_TYPE_ETHERNET  = 6,
 IF_TYPE_TOKENRING = 9,
 IF_TYPE_FDDI      = 15,
 IF_TYPE_PPP       = 23,
 IF_TYPE_LOOPBACK  = 24,
 IF_TYPE_SLIP      = 28
 
-- Operational status of the interface
constant IfoperStatusDesc = {
 "The interface is up and operational.", -- IfOperStatusUp = 1  	
 "The interface is not operational.",	   -- IfOperStatusDown = 2
 "The interface is being tested.",	   -- IfOperStatusTesting = 3
 "The interface status is unknown.",     -- IfOperStatusUnknown  = 4
 "The interface is dormant.",            -- IfOperStatusDormant = 5
 "The interface is not present.",        -- IfOperStatusNotPresent = 6
 "The interface is operational, but a networking layer " &
  "below the interface is not operational."  --IfOperStatusLowerLayerDown = 7
	} 

function GetAdapterName(atom pName)
sequence name
integer i,wc
 name = ""
 wc = peek(pName) 
 i = 0
 while wc do
  name &= wc
  i += 1
  wc = peek(pName+i) 
 end while
 return name
end function

function GetUnicodeData(atom ptr)
sequence name
integer i,wc
 name = ""
 wc = peek(ptr) + peek(ptr+1)*256
 i = 0
 while wc do
  name &= wc
  i += 2
  wc = peek(ptr+i) + peek(ptr+i+1)*256
 end while
 return name
end function


global function GetAdaptersAddresses()
 atom struct, pOutBufLen, dwStatus, flags,
 		num, pNext
 integer dhcp, dDNS, interface_type
 sequence FriendlyName, Description, macAddr, DnsSuffix, operStatus
 object data
 data = {}

  struct = allocate(78)
  pOutBufLen = allocate(4)
  poke4( pOutBufLen,4 )  -- poke the wrong size for first call
dwStatus = c_func( xGetAdaptersAddresses, {AF_INET, 0, NULL, struct,
  pOutBufLen} )
  if dwStatus != ERROR_BUFFER_OVERFLOW then
     data = dwStatus
  else
     free(struct)
     struct = allocate(peek4u(pOutBufLen))
     mem_set(struct,0,peek4u(pOutBufLen))
dwStatus = c_func(xGetAdaptersAddresses,{AF_INET, 0, NULL, struct,
     pOutBufLen})
     if dwStatus = ERROR_SUCCESS then
       pNext = struct
       data = {}
       while pNext do
       	 FriendlyName = GetUnicodeData(peek4u(pNext+40))
       	 Description  = GetUnicodeData(peek4u(pNext+36))
       	 DnsSuffix    = GetUnicodeData(peek4u(pNext+32))
         interface_type = peek4u(pNext+64)
         macAddr	  = peek({pNext+44, peek4u(pNext+52)})
         operStatus = IfoperStatusDesc[peek4u(pNext+68)]
         flags = peek4u(pNext+56)
         if and_bits(IP_ADAPTER_DHCP_ENABLED, flags) then
         	dhcp = 1
         else
         	dhcp = 0
         end if 
         if and_bits(IP_ADAPTER_DDNS_ENABLED, flags) then
         	dDNS = 1
         else
         	dDNS = 0
         end if    
         data &= {{interface_type, GetAdapterName(peek4u(pNext+12)), 
         			FriendlyName, Description, macAddr,
         			operStatus, dhcp, dDNS, DnsSuffix}}
         pNext = peek4u(pNext+8)
       end while
     else
       data = dwStatus
     end if
  end if
  free(struct)
  free(pOutBufLen)
  return data
end function


 object data
data = GetAdaptersAddresses()
if sequence(data) then
	for i = 1 to length(data) do
	  if data[i][ADAPTER_TYPE] != IF_TYPE_LOOPBACK then
     printf(1,"Type: %d,\n", data[i][ADAPTER_TYPE])
	    printf(1,"    Name: %s,\n", {data[i][ADAPTER_NAME]})
	    printf(1,"    Friendly name: %s,\n",{data[i][ADAPTER_FRIENDLYNAME]})
	    printf(1,"    description: %s,\n", {data[i][ADAPTER_DESCRIPTION]})
printf(1,"    Mac Addr: %02x-%02x-%02x-%02x-%02x-%02x,\n",
data[i][ADAPTER_MAC_ADDRESS])
	    printf(1,"    Oper Status: %s,\n", {data[i][ADAPTER_STATUS]})
	    printf(1,"    DHCP Enabled: %d,\n", data[i][DHCP_ENABLED])
	    printf(1,"    DNS Enabled: %d,\n", data[i][DYNAMIC_DNS])
	    printf(1,"    DNS Suffix: %s,\n", {data[i][DNS_SUFFIX]})	
	  end if
	end for
end if

I would still like to know why the addition of one blank line can cause or fix
  my original failure, but I think Rob is the only man to answer that one. At least
  your code has shown me how to access a structure without Win32lib, and I wanted
  to be able to remove any win32lib dependencies on this anyway.
Thanks!

PeteS
ps. I will let you know if I see any more failures using this version!

14. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Vincent <darkvincentdude at yahoo.com> Mar 01, 2006
• 678 views

Robert Craig wrote:

> This rarely means there's a bug in the interpreter. It usually means
> that you are doing something that isn't "kosher". 
> 
> If you change a program in any way, the memory addresses of variables
> and other blocks of memory, as well as the contents of memory can change.
> 
> In some cases you can instantly find your problem by copying 
> euphoria\include\safe.e into the same directory as your main 
> program file, and then renaming safe.e as machine.e in that directory. 
> Now when you run your program, a whole bunch of extra memory checks 
> will occur, and you might get an error message on the screen telling
> you, for example, that you are poking into some memory that 
> doesn't belong to you.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

Rob,

Are you sure that is whats wrong?

I don't know... I find it very awkward that simply adding or removing white
space can adversely affect program operation.


Regards,
Vincent

16. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Robert Craig <rds at RapidEuphoria.com> Mar 01, 2006
• 693 views

Vincent wrote:
> Are you sure that is whats wrong?
> 
> I don't know... I find it very awkward that simply adding or removing white
> space can adversely affect program operation.

People are always amazed when this type of thing occurs,
but believe me, it's not that uncommon. It has happened to me,
and it has happened to many other people on EUforum over the
years. If your program is making decisions based on random
garbage in memory, it can sometimes work with certain garbage,
and crash or malfunction with other garbage.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

18. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Vincent <darkvincentdude at yahoo.com> Mar 01, 2006
• 665 views

Robert Craig wrote:

> People are always amazed when this type of thing occurs,
> but believe me, it's not that uncommon. It has happened to me,
> and it has happened to many other people on EUforum over the
> years. If your program is making decisions based on random
> garbage in memory, it can sometimes work with certain garbage,
> and crash or malfunction with other garbage.

This hasn't happened to me, at least not yet anyway, but I suppose that could
make a little sense. Perhaps it's just a bug in Win32Lib like Jason suggests.


Regards,
Vincent

20. Re: Very strange problem - Eu bug?? (Eu 2.5)

• Posted by Al Getz <Xaxo at aol.com> Mar 01, 2006
• 700 views
• Last edited Mar 02, 2006

Kat wrote:
> 
> Robert Craig wrote:
> 
> > People are always amazed when this type of thing occurs,
> > but believe me, it's not that uncommon. It has happened to me,
> > and it has happened to many other people on EUforum over the
> > years. If your program is making decisions based on random
> > garbage in memory, it can sometimes work with certain garbage,
> > and crash or malfunction with other garbage.
> 
> So the interpreter sees whitespace IN THE SOURCE CODE as something it should
> translate to .il code as pointers to various undefined garbage?!? And then
> attempt
> to run it? What part of the Eu syntax is defined as "...and this 
> lack of keyword controls how whitespace is processed..."? It's not only 
> whitespace, it's done it to me before with a "--" added to a program to 
> comment out a trace(1) line.
> 
> 
> Kat,
> one of those who complained about this sort of bug before.

Hi Kat,

Nice to see you posting to the list again.

I've had this problem with v2.4 and earlier, but ALWAYS traced it back
to some memory location that was being poked that wasnt supposed to
be changed.  I figured it was poking in where the interp resides, and
that's why i'd get a *totally* different error complaint from Eu
each time i changed one iddie biddie thing in the source file, even
if it had *absolutely* nothing to do with the program such as 
whitespace, comments (add a few extra "--" in a line that was already
commented), strings inclosed in quotes ("hello" to "hello1"), etc.
Once the mem problem was found and corrected the error always cleared up.

I dont know for sure if this is the same with v2.5 but i'd be sure
to double check how pointers are allocated, free'd, and used in 
my program if i got these kinds of errors.


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"