Re: Graphic Display
On Wed, 13 Sep 2000, opus.species wrote: > > Scott Raney <[EMAIL PROTECTED]> wrote: > > > > Both of these problems are almost certainly due to bugs and other > > non-features in drivers for the graphics card you're using and not > > anything to do with the hardware or OS. The standard procedure for > > dealing with these is: > > 1) Make sure you have the absolute latest drivers from the vendor's > > WWW site. > > 2) Disable acceleration in the Display and/or System control panel. > > Trying other screen resolutions or color depths might also be a > > workaround. > > 3) Find a reproducible example and report it to the vendor and insist > > that they fix it. We're always happy to help any vendor identify and > > fix the problem, but have yet to be contacted by any of them even when > > we ourselves have reported the bugs to them. Sometimes the bug > > quietly gets fixed in a new driver version, but more commonly the > > vendor just blows off anyone that reports bugs like this. > > 4) Get a different, more reliable, graphics card. > > Unfortunately we can not always choose our customers nor let them buy new > computers ... so we have to get workarounds ! It's perfectly acceptable for you to expect your customer to have a working system, and if they don't, to get them to upgrade or reconfigure it so that it works right. There's a really serious problem with the idea that you have to expend more than a token effort to try to make your application work on all systems. You may end up losing a significant number of sales (perhaps even a majority) to the 99% of potential customers with working systems who don't buy it because they need some feature that you can't provide because you're wasting so much time (and/or giving up so much design flexibility) trying to work around problems that only affect the 1% who bought some piece of junk computer and don't know how (or care to learn how) to fix it. At some point you just have to write the losers off... > According to my tests, there are "incompatibility problems" between MC, some > video card drivers and some non-really-standard file formats. > > - MC display always OK the RVB jpegs, but display sometimes bad the > gray-level jpegs or the "optimized" jpegs. There were problems displaying some types of JPEGs 2.3.1 and previous releases, but these should all be fixed in 2.3.2. These are independent of the graphics card problem because a given image would look wrong on *all* systems. > - MC display always OK the ordinary gifs, but display sometimes bad the > transparent gifs Sometimes these can be fixed by setting the constantMask property to true, but sometimes it's a driver problem (masked images are usually the most common place to see these problems). Again, it depends on whether the image appears correct on some systems, or wrong on all of them. > For jpegs, the workaround is easy : open the files in Photoshop, transform > as rvb images and save as standard jpeg files. > The same for plain gifs. > > For animated or transparent gifs, i am still looking for a reliable > solution. I've got one: Only distribute your application on UNIX and MacOS systems, which AFAIK never have these kinds of graphics-card dependent problems ;-) Regards, Scott > Regards, > Claude Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Question about 2.3.2
On Wed, 13 Sep 2000, David Bovill wrote: > Trying Metacard beta 2.3.2, and nice to see tow of my top wish list features > in it - sound control for QuickTime and better resolving of URL's with the > built in HTTP features. Thanks. > > > From: Scott Raney <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > Date: Mon, 11 Sep 2000 12:02:48 -0600 (MDT) > > To: [EMAIL PROTECTED] > > Subject: Re: client side http > > > > On Mon, 11 Sep 2000, Dave Cragg wrote: > > > > 2.3.2 already has one new feature that will make implementing such a > > library much easier: a "wait for messages" command which allows event > > dispatching within a handler. This is useful for building synchronous > > function calls that still require some event dispatching (e.g., one > > that does the equivalent of "get url http://somehost/somefile"). > > > > This sounds like something I've always wanted. Is there any documentation on > this feature. I've downloaded 2.3.2 for the Mac and read the readme, but... > > What would be the best tactic now for doing something like background > indexing of text fields? I have a complex indexing scheme which takes some > time for each piece of text, I want to be able to index these in passes > without interrupting the working environment. > > Can I use "wait for message" in some way to do this? I am guessing that > while it is waiting other scripts can execute? Can I use this to effectively > do: > > wait for message "notDoingAnythingTest" > continueIndexingALittle > wait for message "notDoingAnythingTest" > continueIndexingALittleMore You could do it this way, but using "send .. in" would make a lot more sense. Note that "send .. in" messages are also only sent when there aren't any OS-generated events in the queue, which means that interactivity always has priority over these background tasks. You do still have to exit from your "continueIndexingALittleMore" handler after a short time (say, 200ms) periodically, though. Regards, Scott Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Apple has released Mac OS X Beta
on 9/13/2000 6:51 PM, "Geoff Canyon" <[EMAIL PROTECTED]> gloated: > > It's not downloadable--you have to buy the cd for $29. > > Does it make me a simpering MacFool that I already ordered mine? Don't > answer that. :-) > > http://www.apple.com I can't order it. My iMac has only 96 MB of RAM. Sigh. Maybe they will get the memory requirements down. Then again, maybe not. At least MetaCard has a reasonable memory requirement! Raymond Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: "lock screen" doesn't?
on 9/13/00 4:36 PM, Dave Cragg at [EMAIL PROTECTED] wrote: > If you need to control the visibility from the calling stack, I think > you can use the following (from memory): > > open invisible stack theStackFile This worked. I also had a vague memory about the invisible keyword, but I didn't see it in the MetaCard documentation. It is in the SuperCard (not HyperCard) documentation. I did see in the MetaCard docs that "open" in this sense is simply mapped to "go" in MetaCard, so: go invisible stack theStackFile --worked as well I assume the on preOpenStack hide this stack end preOpenStack solution would also work. This one I should have thought of--I _must_ stop trying to code in my sleep! :-) Thanks to all who answered, Geoff Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: "lock screen" doesn't?
Geoff Canyon wrote:
>
> This seems like a simple question, but my pea-brain isn't cooperating with
> me today, so:
>
> I'm using the following code to open a stack invisibly:
>
> set the lockscreen to true --locks the screen?
> if there is a file theStackFile then
> go stack theStackFile --shouldn't show, but does
> hide stack "prefs" --then hides here
> end if
> go stack "Main"
>
> And it isn't working. When it executes, the second stack, indicated by
> theStackFile above, flashes into existence visibly before hiding.
>
> First, is there a better way to do this? I want to store the second stack
> ("theStackFile") separately, because it will be modified, and you can't
> modify a standalone. Second, why isn't the lockScreen property actually
> locking the screen through opening the second stack? Doesn't it do that?
Under posix systems (Linux, BSD, and unixes), you can load the stack as a
bagrounder (non graphical) process using a .mt script saying :
on startup
open stack "the needed stack"
end startup
witch has to be lauched at boot time by a System V init script.
Not sure that the equivalent is avalaible on MacOS9, even using applescript,
keyquencer or quickeys at boottime.
>
> Thanks
>
> gc
>
> Archives: http://www.mail-archive.com/metacard%40lists.best.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <[EMAIL PROTECTED]>, not this list.
--
Pierre Sahores
WEB, DB, B2B & ASP design.
Because people develop knowledge from scratch
rather than being born with built-in knowledge,
we can adapt to different circumstances.
Sampson, Geoffrey. Educating Eve :
The "Language Instinct" debate.
London: Cassell, 1997 [1999].
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Apple has released Mac OS X Beta
On Thu, 14 Sep 2000, Pierre Sahores wrote: > Geoff Canyon wrote: > > > > It's not downloadable--you have to buy the cd for $29. > > > > Does it make me a simpering MacFool that I already ordered mine? Don't > > answer that. :-) > > > > http://www.apple.com > > > > Archives: http://www.mail-archive.com/metacard%40lists.best.com/ > > Info: http://www.xworlds.com/metacard/mailinglist.htm > > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Scott, > > Is it a way to get the FreeBSD issue of Metacard running under the beta of this > new MacOS X version ? No, that's for Intel processors. An equivalent engine will probably be made available for Mac OS X, but it will be different from the Carbon engine (sort of like the Win32 console engine is different from the regular Win32 engine). Regards, Scott > Thank's, Pierre Sahores > > WEB, DB, B2B & ASP design. > Because people develop knowledge from scratch > rather than being born with built-in knowledge, > we can adapt to different circumstances. > Sampson, Geoffrey. Educating Eve : > The "Language Instinct" debate. > London: Cassell, 1997 [1999]. Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Trapping Errors
Gary Rathbone wrote: > > Its all Mac based and I'm using MC as an HTTP server with additional code to > process forms. It works a treat... until I make a mistake like a typo... > > If I type : > > on mouseUp > put "thtml" ito "pageout" > end mouseUp > > into the button script of any stack, its accepted ie no semantic error. When > I click on the button however an error "Cant find handler" along with line > number and other error info is presented in the Execution Error dialog box. > Great - enough info to locate and fix the problem. > > Now if the above routine is called by a browser through a socket connection > to an MC stack then MC doesn't present the same Execution Error box and the > only clue that something is wrong is that nothing is returned to the > browser. Hence manually searching through the code. Any ideas ? Nothing better than putting a serie of put "ok1" to put "ok10" in the body of the suspected script to detect where it goes to scratch from the msg box. > > on 13/9/00 5:11 pm, David Bovill at [EMAIL PROTECTED] wrote: > > > Test your CGI's thoroughly offline first. When I was doing this a while back > > I used a Metacard stack to process forms and act as a spoof browser for this > > job. > > > > Are you using ".mt" scripts or the Metacard based HTTP server? > > > >> From: Gary Rathbone <[EMAIL PROTECTED]> > >> Reply-To: [EMAIL PROTECTED] > >> Date: Wed, 13 Sep 2000 16:37:30 +0100 > >> To: [EMAIL PROTECTED] > >> Subject: Trapping Errors > >> > >> I'm writing an increasing number of complex cgi's using Metacard (What a > >> tool !) > >> I submit a page from by browser and metacard processes the request and > >> returns the required result. However should I (an I often do) have a typo in > >> my script eg: > >> > >> "put thtmlpage ito thtmlout" > >> > >> the browser 'sticks' as MC can't produce the results due to the error. In > >> this instance MC doesn't return any error information and I have to search > >> through the script line by line to hopefully find my mistake. > >> > >> Q: Can I return a 'readable' MC error message to the browser or even put a > >> message into an error field on the stack ? I guess I need to write my own > >> error routines...If so can anyone give me any pointers ? > >> > >> TIA > >> > >> Gary Rathbone > >> Pierre Sahores CNDP 91, rue Gabriel-Peri 92120 Montrouge Because people develop knowledge from scratch rather than being born with built-in knowledge, we can adapt to different circumstances. Sampson, Geoffrey. Educating Eve : The "Language Instinct" debate. London: Cassell, 1997 [1999]. Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: "lock screen" doesn't?
On 13/9/00 11:51 pm, Geoff Canyon <[EMAIL PROTECTED]> wrote:
> This seems like a simple question, but my pea-brain isn't cooperating with
> me today, so:
>
> I'm using the following code to open a stack invisibly:
>
> set the lockscreen to true --locks the screen?
> if there is a file theStackFile then
> go stack theStackFile --shouldn't show, but does
> hide stack "prefs" --then hides here
> end if
> go stack "Main"
>
> And it isn't working. When it executes, the second stack, indicated by
> theStackFile above, flashes into existence visibly before hiding.
>
> First, is there a better way to do this? I want to store the second stack
> ("theStackFile") separately, because it will be modified, and you can't
> modify a standalone. Second, why isn't the lockScreen property actually
> locking the screen through opening the second stack? Doesn't it do that?
Lock screen does not prevent the display of a stack that you are opening.
It prevents changes inside the contents of stacks that are on screen. To do
what you want to do, you need to add a line that sets the visible of that
stack to false before you open it.
Regards,
Kevin
> Thanks
>
> gc
Kevin Miller <[EMAIL PROTECTED]>
Re: "lock screen" doesn't?
At 3:51 PM -0700 9/13/00, Geoff Canyon wrote:
>This seems like a simple question, but my pea-brain isn't cooperating with
>me today, so:
>
>I'm using the following code to open a stack invisibly:
>
> set the lockscreen to true --locks the screen?
> if there is a file theStackFile then
> go stack theStackFile --shouldn't show, but does
> hide stack "prefs" --then hides here
> end if
> go stack "Main"
>
>And it isn't working. When it executes, the second stack, indicated by
>theStackFile above, flashes into existence visibly before hiding.
>
>First, is there a better way to do this? I want to store the second stack
>("theStackFile") separately, because it will be modified, and you can't
>modify a standalone. Second, why isn't the lockScreen property actually
>locking the screen through opening the second stack? Doesn't it do that?
If the second stack (theStackFile) is always to be invisible when
opened, you could do this in a preOpenStack handler.
on preOpenStack
hide this stack
end preOpenStack
If you need to control the visibility from the calling stack, I think
you can use the following (from memory):
open invisible stack theStackFile
Cheers
Dave Cragg
--
_
The LACS Centre (Business English Training Resources)
mailto:[EMAIL PROTECTED]
http://www.lacscentre.co.uk
_
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Tired Eyes - Script Editor Type
Gary Rathbone wrote: > > >From my previous post re: > --snip-- > And just one more All these late nights working on MC code are hurting > my eyes. Does anyone know how I can change the default typeface of the > script window to something that I find more readable ? > --snip-- > > I now use a button on my stack whose script reads... > > on mouseUp > edit the script of this card > set the textsize of wd "Script Editor 1" to 12 > set the textfont of wd "Script Editor 1" to "Monaco" > end mouseUp > > For me this makes editing my scripts easier and quicker as I don't have to > switch from the browse tool and can set the type according to how awake I > feel... > > Not perhaps the most 'revolutionary' tip, but may be of use to someone... > > Rgds > > Gary Rathbone > > Archives: http://www.mail-archive.com/metacard%40lists.best.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. Realy usefull, thank's Garry Pierre Sahores WEB, DB, B2B & ASP design. Because people develop knowledge from scratch rather than being born with built-in knowledge, we can adapt to different circumstances. Sampson, Geoffrey. Educating Eve : The "Language Instinct" debate. London: Cassell, 1997 [1999]. Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
"lock screen" doesn't?
This seems like a simple question, but my pea-brain isn't cooperating with
me today, so:
I'm using the following code to open a stack invisibly:
set the lockscreen to true --locks the screen?
if there is a file theStackFile then
go stack theStackFile --shouldn't show, but does
hide stack "prefs" --then hides here
end if
go stack "Main"
And it isn't working. When it executes, the second stack, indicated by
theStackFile above, flashes into existence visibly before hiding.
First, is there a better way to do this? I want to store the second stack
("theStackFile") separately, because it will be modified, and you can't
modify a standalone. Second, why isn't the lockScreen property actually
locking the screen through opening the second stack? Doesn't it do that?
Thanks
gc
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Apple has released Mac OS X Beta
Geoff Canyon wrote: > > It's not downloadable--you have to buy the cd for $29. > > Does it make me a simpering MacFool that I already ordered mine? Don't > answer that. :-) > > http://www.apple.com > > Archives: http://www.mail-archive.com/metacard%40lists.best.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. Scott, Is it a way to get the FreeBSD issue of Metacard running under the beta of this new MacOS X version ? Thank's, Pierre Sahores WEB, DB, B2B & ASP design. Because people develop knowledge from scratch rather than being born with built-in knowledge, we can adapt to different circumstances. Sampson, Geoffrey. Educating Eve : The "Language Instinct" debate. London: Cassell, 1997 [1999]. Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Apple has released Mac OS X Beta
It's not downloadable--you have to buy the cd for $29. Does it make me a simpering MacFool that I already ordered mine? Don't answer that. :-) http://www.apple.com Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Trapping Errors
Its all Mac based and I'm using MC as an HTTP server with additional code to process forms. It works a treat... until I make a mistake like a typo... If I type : on mouseUp put "thtml" ito "pageout" end mouseUp into the button script of any stack, its accepted ie no semantic error. When I click on the button however an error "Cant find handler" along with line number and other error info is presented in the Execution Error dialog box. Great - enough info to locate and fix the problem. Now if the above routine is called by a browser through a socket connection to an MC stack then MC doesn't present the same Execution Error box and the only clue that something is wrong is that nothing is returned to the browser. Hence manually searching through the code. Any ideas ? on 13/9/00 5:11 pm, David Bovill at [EMAIL PROTECTED] wrote: > Test your CGI's thoroughly offline first. When I was doing this a while back > I used a Metacard stack to process forms and act as a spoof browser for this > job. > > Are you using ".mt" scripts or the Metacard based HTTP server? > >> From: Gary Rathbone <[EMAIL PROTECTED]> >> Reply-To: [EMAIL PROTECTED] >> Date: Wed, 13 Sep 2000 16:37:30 +0100 >> To: [EMAIL PROTECTED] >> Subject: Trapping Errors >> >> I'm writing an increasing number of complex cgi's using Metacard (What a >> tool !) >> I submit a page from by browser and metacard processes the request and >> returns the required result. However should I (an I often do) have a typo in >> my script eg: >> >> "put thtmlpage ito thtmlout" >> >> the browser 'sticks' as MC can't produce the results due to the error. In >> this instance MC doesn't return any error information and I have to search >> through the script line by line to hopefully find my mistake. >> >> Q: Can I return a 'readable' MC error message to the browser or even put a >> message into an error field on the stack ? I guess I need to write my own >> error routines...If so can anyone give me any pointers ? >> >> TIA >> >> Gary Rathbone >> >> Archives: http://www.mail-archive.com/metacard%40lists.best.com/ >> Info: http://www.xworlds.com/metacard/mailinglist.htm >> Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > > Archives: http://www.mail-archive.com/metacard%40lists.best.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Trapping Errors
Test your CGI's thoroughly offline first. When I was doing this a while back I used a Metacard stack to process forms and act as a spoof browser for this job. Are you using ".mt" scripts or the Metacard based HTTP server? > From: Gary Rathbone <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Wed, 13 Sep 2000 16:37:30 +0100 > To: [EMAIL PROTECTED] > Subject: Trapping Errors > > I'm writing an increasing number of complex cgi's using Metacard (What a > tool !) > I submit a page from by browser and metacard processes the request and > returns the required result. However should I (an I often do) have a typo in > my script eg: > > "put thtmlpage ito thtmlout" > > the browser 'sticks' as MC can't produce the results due to the error. In > this instance MC doesn't return any error information and I have to search > through the script line by line to hopefully find my mistake. > > Q: Can I return a 'readable' MC error message to the browser or even put a > message into an error field on the stack ? I guess I need to write my own > error routines...If so can anyone give me any pointers ? > > TIA > > Gary Rathbone > > Archives: http://www.mail-archive.com/metacard%40lists.best.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Trapping Errors
I'm writing an increasing number of complex cgi's using Metacard (What a tool !) I submit a page from by browser and metacard processes the request and returns the required result. However should I (an I often do) have a typo in my script eg: "put thtmlpage ito thtmlout" the browser 'sticks' as MC can't produce the results due to the error. In this instance MC doesn't return any error information and I have to search through the script line by line to hopefully find my mistake. Q: Can I return a 'readable' MC error message to the browser or even put a message into an error field on the stack ? I guess I need to write my own error routines...If so can anyone give me any pointers ? TIA Gary Rathbone Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Tired Eyes - Script Editor Type
>From my previous post re: --snip-- And just one more All these late nights working on MC code are hurting my eyes. Does anyone know how I can change the default typeface of the script window to something that I find more readable ? --snip-- I now use a button on my stack whose script reads... on mouseUp edit the script of this card set the textsize of wd "Script Editor 1" to 12 set the textfont of wd "Script Editor 1" to "Monaco" end mouseUp For me this makes editing my scripts easier and quicker as I don't have to switch from the browse tool and can set the type according to how awake I feel... Not perhaps the most 'revolutionary' tip, but may be of use to someone... Rgds Gary Rathbone Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: client side http
At 7:55 PM -0400 9/11/00, andu wrote: >>How to handle http proxies? Is this just a question of opening the >>socket to the proxy and carrying on as before, or is it, as I fear, >>more torturous? > >Yes, take a look at my ftp client (http://www.cloud9.net/~undo) >which handles proxy, it should be the same. >It also shows you how I handled the progress bar and others. Thanks Andu. I already have your ftp stack. A case of stupidity made me forget that it implemented a progress bar. Still, hacking around in the dark with an rfc document and a lot of coffee was interesting (I won't say enjoyable. :)) Please keep up the good work. Cheers Dave Cragg -- _ The LACS Centre (Business English Training Resources) mailto:[EMAIL PROTECTED] http://www.lacscentre.co.uk _ Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Question about 2.3.2
Trying Metacard beta 2.3.2, and nice to see tow of my top wish list features in it - sound control for QuickTime and better resolving of URL's with the built in HTTP features. Thanks. > From: Scott Raney <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Mon, 11 Sep 2000 12:02:48 -0600 (MDT) > To: [EMAIL PROTECTED] > Subject: Re: client side http > > On Mon, 11 Sep 2000, Dave Cragg wrote: > > 2.3.2 already has one new feature that will make implementing such a > library much easier: a "wait for messages" command which allows event > dispatching within a handler. This is useful for building synchronous > function calls that still require some event dispatching (e.g., one > that does the equivalent of "get url http://somehost/somefile"). > This sounds like something I've always wanted. Is there any documentation on this feature. I've downloaded 2.3.2 for the Mac and read the readme, but... What would be the best tactic now for doing something like background indexing of text fields? I have a complex indexing scheme which takes some time for each piece of text, I want to be able to index these in passes without interrupting the working environment. Can I use "wait for message" in some way to do this? I am guessing that while it is waiting other scripts can execute? Can I use this to effectively do: wait for message "notDoingAnythingTest" continueIndexingALittle wait for message "notDoingAnythingTest" continueIndexingALittleMore Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: htmlText - problem and feature request...
At 3:11 PM -0700 9/12/2000, Scott Raney <[EMAIL PROTECTED] wrote: >The tags really serve no purpose, even in browsers. They're >more for content-management tools to use. The tag is a stylesheet tag and removing it will remove the page's style sheet. Which is quite a change. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Digest metacard.v003.n503
> From: Scott Raney <[EMAIL PROTECTED]> > Subject: Re: Graphic Display > Date: Sat, 9 Sep 2000 17:31:11 -0600 (MDT) > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > In-Reply-To: <[EMAIL PROTECTED]> > > On Sat, 9 Sep 2000, Eva Isotalo wrote: > > > Similar happens here. I've a new Athlon 700 Mhz which behaves strange. > > Images are often gray at first. There are long delays between opening > > stacks and such. The Win machine I had before was 233 Mhz Intel > > don't remember but it worked much smother than this one. > > > > We found one "reason" for strange behavior - if screen resolution is set > > to the highest (I'm not with the Win-machine right now so I don't know > > the messurements, but 2 steps over 800x640) and Color to 16 bit, then > > palette stack are not drawn properly. Sometimes they are there and > > sometimes not. When lowering resolution one step this problem went away. > > > > But besides that we haven't a clue why it seems slower on a faster > > machine. > > Both of these problems are almost certainly due to bugs and other > non-features in drivers for the graphics card you're using and not > anything to do with the hardware or OS. The standard procedure for > dealing with these is: > 1) Make sure you have the absolute latest drivers from the vendor's > WWW site. > 2) Disable acceleration in the Display and/or System control panel. > Trying other screen resolutions or color depths might also be a > workaround. > 3) Find a reproducible example and report it to the vendor and insist > that they fix it. We're always happy to help any vendor identify and > fix the problem, but have yet to be contacted by any of them even when > we ourselves have reported the bugs to them. Sometimes the bug > quietly gets fixed in a new driver version, but more commonly the > vendor just blows off anyone that reports bugs like this. > 4) Get a different, more reliable, graphics card. > > In any case, it would be helpful to know which specific graphics > adapters you see these problems with so that we can warn others not to > buy them. > Regards, > Scott > > > Regards, > > Eva > > > > Scott Raney [EMAIL PROTECTED] http://www.metacard.com > MetaCard: You know, there's an easier way to do that... Unfortunately we can not always choose our customers nor let them buy new computers ... so we have to get workarounds ! According to my tests, there are "incompatibility problems" between MC, some video card drivers and some non-really-standard file formats. - MC display always OK the RVB jpegs, but display sometimes bad the gray-level jpegs or the "optimized" jpegs. - MC display always OK the ordinary gifs, but display sometimes bad the transparent gifs For jpegs, the workaround is easy : open the files in Photoshop, transform as rvb images and save as standard jpeg files. The same for plain gifs. For animated or transparent gifs, i am still looking for a reliable solution. Regards, Claude Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
