Re: mollases mode
I had a similar problem on windows. I had an application which had to run 24/7 and which would slow down after a couple of days. I was storing all communication in and out in a field which was supposed to be truncated to 200 lines but, the truncation code didn't work right. This meant that the field just kept growing. I also noticed that my memory usage hadn't increased dramatically but my processor usage did go high. Basically, check to see if you have a field or a variable which is being allowed to grow infinitely. Since it's a CGI, I suspect you're doing some logging Rich Mooney Payne Sparkman Mfg. I do log but I checked that the truncation works as expected. I am starting to suspect that I have an infinite loop somewhere in a seldom used chunk of code. I am planning to slave through the logs when I find some spare time. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Sannyasin Sivakatirswami a écrit : mmm interesting replace the standard web forms in most of the next production apps how can MC replace an HTML Web form? do you mean you will distribute MC stacks and the user won't go through a browser? Exactly ! In using MC 2.4.3/libURL 1.0.8 if possible, MC 2.4.3/home-made TCP/IP protocol else. The main features expected from this is to have a client-side stack-based front-end (1) able to work in both unconected/conected modes, (2) to post, time to time, datas to a remote mc/pg server, (3) to print fine formated docs and (4) to export RTF formated files from the contents of the stack. It's right on the desk what i'm working on those days ;-) Sivakatirswami On Wednesday, December 18, 2002, at 10:38 AM, Pierre Sahores wrote: In betwin : i'm working on the client-side front-end of the Citalis tests db and expect to use a dedicated metacard 2.43 stack to manage the sql insert, update and delete queries. If i get the needed results in using the libURL 1.0.8 POST command abilities, the mc front-end will replace the standard web forms in most of the nexts production apps to come. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard -- Cordialement, Pierre Sahores Inspection académique de Seine-Saint-Denis. Applications et bases de données WEB et VPN Qualifier et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Alain Farmer a écrit : Hello, Excuse me for budding in but ... YEAH! How can MC replace an HTML Web form? Use MetaCard's widgets instead of the poor unreliable ones that we have to use when using HTML to create the form and JavaScript to make it interactive. Instead of the submit button, your script then POSTs the fields of the MetaCard-based form to a CGI. No need for any HTML or any JavaScript. Everything from within MetaCard, and the fact that MC runs on ANY platform achieves the same multi-platform-ness as the web-only solution. But MetaCard's interactivity far surpasses what can ever be achieved by even the most-creative JavaScript scriptor. Interactive validation of the fields, for example, is a cinch in MetaCard. Adjusting the contents of one or more subsequent popup menus, according to what the user fills in to the form, is also a cinch to implement; night-and-day when compared to HTML and JavaScript. Just as you say, Alain and we, all, are going to open l'avenue des Champs-Elysees to the web-dedicated metacard developments. Because they did'nt know it was impossible,... ;-) Do you mean you will distribute MC stacks and the user won't go through a browser? You certainly can. Let's conquer the Web with MetaCard, Alain Farmer __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard -- Cordialement, Pierre Sahores Inspection académique de Seine-Saint-Denis. Applications et bases de données WEB et VPN Qualifier et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Are you speaking from the indexes page form submit javascript ? It works ok under Netscape 4.7, different issues of Explorer, Mozilla 1.3 and Opera 5 under Linux, Jaguar, Win98 and Win2K. It's a javascript 1.5 specs code. In the iCab prefs (inScript) all the specs are checked, from 1.0 to 1.5. iCab presents itself as MS Exploder 5.0 ;-) In fact, the page is briefly displayed, I can see that a lgin and a password are asked for... and iCabs quits silently on an error 2. I have to state that iCab is plagued with those error 2 since a number of versions... It is still a preview version, made by a very small developer team. I don't like behemoths such as Netscape Navigator, and my disk is nearly MS-Free ;-) -- Regards, (-8 Dominique ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Dominique a écrit : Are you speaking from the indexes page form submit javascript ? It works ok under Netscape 4.7, different issues of Explorer, Mozilla 1.3 and Opera 5 under Linux, Jaguar, Win98 and Win2K. It's a javascript 1.5 specs code. In the iCab prefs (inScript) all the specs are checked, from 1.0 to 1.5. iCab presents itself as MS Exploder 5.0 ;-) In fact, the page is briefly displayed, I can see that a lgin and a password are asked for... and iCabs quits silently on an error 2. I have to state that iCab is plagued with those error 2 since a number of versions... It is still a preview version, made by a very small developer team. I don't like behemoths such as Netscape Navigator, and my disk is nearly MS-Free ;-) -- Regards, (-8 Dominique ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Did you try Opera 5 (Andu said, previously, that Opera 6 linux is bugged) or, else Mozilla, whoses works fine there on both Linux and Jaguar ? -- Cordialement, Pierre Sahores Inspection académique de Seine-Saint-Denis. Applications et bases de données WEB et VPN Qualifier et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
--On Thursday, December 19, 2002 15:00:53 +0100 Pierre Sahores [EMAIL PROTECTED] wrote: Did you try Opera 5 (Andu said, previously, that Opera 6 linux is bugged) or, else Mozilla, whoses works fine there on both Linux and Jaguar ? When it comes to browsers they should be considered bugged when they work... I'd like to understand why people use javascript when they can do with plain html. -- Cordialement, Pierre Sahores Inspection académique de Seine-Saint-Denis. Applications et bases de données WEB et VPN Qualifier et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
andu a écrit : --On Thursday, December 19, 2002 15:00:53 +0100 Pierre Sahores [EMAIL PROTECTED] wrote: Did you try Opera 5 (Andu said, previously, that Opera 6 linux is bugged) or, else Mozilla, whoses works fine there on both Linux and Jaguar ? When it comes to browsers they should be considered bugged when they work... I'd like to understand why people use javascript when they can do with plain html. Allo Andu, I agree with you. Most browser-side problems are happening in parsing .js code. Do you have a way you use to manage selectoption... tags conditional selections in plain html ? if yes, i would realy be intersted in learning the method you use. Thanks :) Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard -- Cordialement, Pierre Sahores Inspection académique de Seine-Saint-Denis. Applications et bases de données WEB et VPN Qualifier et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Recently, andu wrote: I'd like to understand why people use javascript when they can do with plain html. Speaking for myself, Javascript allows me to script interactivity that is not possible with straight HTML: functions, variables, image management, etc. The biggest issue to deal with is consistent (or inconsistent as it were) support of the language across browsers/versions/platforms. I've built some fairly complex Javascripts myself and after wrestling with these issues, it seems to me that Flash is really the way to go: a self-contained environment that runs fairly consistently across most browsers/versions/platforms. Granted, Flash support may be absent on some platforms/browsers, but if your goal is absolute accessibility everywhere, you're pretty much limited to HTML images and text -- kind of like when the Web browser was first introduced. :-) Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
--On Thursday, December 19, 2002 16:49:34 +0100 Pierre Sahores [EMAIL PROTECTED] wrote: andu a écrit : --On Thursday, December 19, 2002 15:00:53 +0100 Pierre Sahores [EMAIL PROTECTED] wrote: Did you try Opera 5 (Andu said, previously, that Opera 6 linux is bugged) or, else Mozilla, whoses works fine there on both Linux and Jaguar ? When it comes to browsers they should be considered bugged when they work... I'd like to understand why people use javascript when they can do with plain html. Allo Andu, I agree with you. Most browser-side problems are happening in parsing .js code. Do you have a way you use to manage selectoption... tags conditional selections in plain html ? if yes, i would realy be intersted in learning the method you use. If you are referring to checking the password length and such I do that server side by good old reliable Metacard, the first lines check the posted data for accuracy before processing it and puts an error message when appropriate. It only take a second or 2 more, besides it's always a good practice to have a little text letting the user know what the restrictions are. It may seem more cumbersome but it's browser safe. Thanks :) Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard -- Cordialement, Pierre Sahores Inspection académique de Seine-Saint-Denis. Applications et bases de données WEB et VPN Qualifier et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
--On Thursday, December 19, 2002 08:54:59 -0800 Scott Rossi [EMAIL PROTECTED] wrote: Recently, andu wrote: I'd like to understand why people use javascript when they can do with plain html. Speaking for myself, Javascript allows me to script interactivity that is not possible with straight HTML: functions, variables, image management, etc. The biggest issue to deal with is consistent (or inconsistent as it were) support of the language across browsers/versions/platforms. I've built some fairly complex Javascripts myself and after wrestling with these issues, it seems to me that Flash is really the way to go: a self-contained environment that runs fairly consistently across most browsers/versions/platforms. Granted, Flash support may be absent on some platforms/browsers, but if your goal is absolute accessibility everywhere, you're pretty much limited to HTML images and text -- kind of like when the Web browser was first introduced. :-) If we talk about public web sites the goal should be absolute accessibility everywhere. Unfortunately as long as somebody is going to make a buck out of it, html will never evolve and the public will be served only half. The excuse that the backward compatibility will sufer is false, people do upgrade when they have a reson. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Web-Dedicated Metacard
I changed the thread on this because I am also following the MC--PostGreSQL closely in its own right... OK, so agreed, we can use Metacard to provide content over the web. I am doing it already in a very small way... but let's we discuss this in a larger context (we got 1.7 million visitors on just three of our domains in 2002... those are visitors, not hits) If one broaches the subject of putting in time to develop content for MC based delivery, saying I can get 20 times the content ready for delivery in the same time it would take to get 1 unit of content out via HTML. (I just spend a month of my time with another team member getting one book on line as HTML... amazing amount of human resources required to do such a simple thing.) The answer is typically Well, that's nice, but you are not going to reach as many people... how many are going to download your plug in? You still have to get them to go via a browser and download your stuff... why not just put it up in html in the first place. So, what kinds of strategies can anyone suggest to take this beyond the consensus reality barrier? On Thursday, December 19, 2002, at 03:35 AM, Pierre Sahores wrote: Just as you say, Alain and we, all, are going to open l'avenue des Champs-Elysees to the web-dedicated metacard developments. Because they did'nt know it was impossible,... ;-) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Recently, andu wrote: If we talk about public web sites the goal should be absolute accessibility everywhere. This is of course a worthy goal, but it's pretty daunting when you run up against lack of standards and inconsistent feature support in browsers. I can't even begin to imagine the trillions of man hours wasted repeatedly by Web development folks who are forced to solve problems caused by idiosyncratic browser behavior. Unfortunately as long as somebody is going to make a buck out of it, html will never evolve and the public will be served only half. The excuse that the backward compatibility will sufer is false, people do upgrade when they have a reson. IMO, HTML has evolved; look at all the spinoffs: DHTML, XML, SMIL, etc. The bigger problem is (lack of) standards. No doubt we are moving that direction with HTML specs, etc, but it's interesting to note that free competition has worked to our disadvantage in this area: while each browser technology attempts to out-feature the other, developers are left having to create workarounds to make their pages accessible everywhere. The original promise of the Web (write once, read anywhere) has been grossly unfulfilled and even undermined by competition. Speaking as someone who has faced these issues for years, I am quite tired of dealing with them and am more than ready to embrace a technology that makes my life easier instead of harder, whether it's Javascript, Flash, or a MetaCard/Web implementation. You're probably be right that someone is making a buck somewhere, but IMO it's at the expense of those folks trying to build sites for a living. Me? Bitter? No... :-) Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
--On Thursday, December 19, 2002 10:42:11 -0800 Scott Rossi [EMAIL PROTECTED] wrote: IMO, HTML has evolved; look at all the spinoffs: DHTML, XML, SMIL, etc. The bigger problem is (lack of) standards. You just mentioned a few, the even bigger problem seems to be sticking to just one ;-). No doubt we are moving that direction with HTML specs, etc, but it's interesting to note that free competition has worked to our disadvantage in this area: while each browser technology attempts to out-feature the other, developers are left having to create workarounds to make their pages accessible everywhere. The original promise of the Web (write once, read anywhere) has been grossly unfulfilled and even undermined by competition. Exactly my point, competition is about money and power not quality. Speaking as someone who has faced these issues for years, I am quite tired of dealing with them and am more than ready to embrace a technology that makes my life easier instead of harder, whether it's Javascript, Flash, or a MetaCard/Web implementation. You're probably be right that someone is making a buck somewhere, but IMO it's at the expense of those folks trying to build sites for a living. Me? Bitter? No... :-) Alone? Hardly.;-) Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Dumb sort question - Tanks Comments
Ken, Sorry for being so late on this topic, but last week has been sort of hectic... Anyway, thanks a lot for your suggestion. I found the time to test it today : it works great but, like the other script submitted by Jacqueline, it becomes rather slow when the amount of data gets large... Best regards, JB jb, I'm sorry that I came in late on this, but here's a way to do it with a custom transposing function... it may not be fast enough, but adapt it to your data and give it a try and let us know your results: on mouseUp -- A sample line number to extract put 3 into theLineToGet put 1 into theItemNumberToSortBy -- Some sample data put b,d,c,a cr 2,4,3,1 cr B,D,C,A cr 20,40,30,10 into tVar -- Transpose the data put transposeIt(tVar) into temp -- Sort it sort lines of temp by item theItemNumberToSortBy of each -- extract line (column) of data, put it into a field put line theLineToGet of transposeIt(temp) into fld 1 end if end mouseUp function transposeIt what -- assumes comma-delimited items and cr-delimited lines put into returnVal put 1 into tItemCounter repeat for each line tLine in what put 1 into tLineCounter if tItemCounter = 1 then -- use replace for quick action on first line of data replace , with cr in tLine put tLine into returnVal else repeat for each item i in tLine put , after line tLineCounter of returnVal put i after line tLineCounter of returnVal add 1 to tLineCounter end repeat end if add 1 to tItemCounter end repeat return returnVal end transposeIt Hope this helps, Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: jbv [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 08, 2002 9:36 AM Subject: Re: Dumb sort question - Tanks Comments Thank you all for your help suggestions. Unfortunately, none of them helped solving my problem... Below you'll find a few more info on what I'm trying to do, comments on some suggestions and finally some feature requests for future versions of MC. Basically, I need to sort a variable featuring 5 lines with a max of 30,000 items each. The sort key could be any of the 5 lines, and after sorting I'd like to extract any line of the variable (get line 3 of myVariable) for further processing. The content of every item of every line can change / evolve continuously. When the variable is organized as 30,000 lines of 5 items each, sorting is a snap (less than 1 second), but then extracting 1 column is impossible... Jacqueline : Thanks for your script : it works great, but when the variable reaches 20,000 items per line, it becomes way too slow... Ray : Yes, the transpose function looks attracting, but unfortunately it only works on arrays. And once the array has been transposed, it seems impossible to extract 1 single line / row. I tried to put the array content into a variable, but it remains stractured as an array... BTW, when the size of a 2 dimensions array reaches a certain limit (5 rows 20,000 column), I get the error message : can't transpose this array (or something similar), while it works fine with 5 rows and 10,000 colums... Is it a bug ? Mr X : Yes, 1 of the Rinaldi externals does that perfectly, but doesn't run on Windoze... Andu and Tariel : Yes, being able to access arrays content via individual rows columns would be a GREAT feature... I'd even dare to say that future versions of MC should implement most of the properties functions associated with spreadsheets in OMO, but applied to arrays, which means : - the ability to split arrays vertically horizontally - the ability to extract individual rows / colums - the ability to sort the content of an array according to sort keys that could be individual rows / colums - a special find function that would work like in OMO spreadsheets : find rows of myTab where item 2 10 would return a comma-separated list of numbers of rows for which this condition is true Actually, spreadsheets in OMO where 1 of the greatest tools I've ever used and I still miss them several years later... Of course, this would work on 1 or 2 dimension arrays; for 3 dimension arrays, things get more complex... Cheers, JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list [EMAIL
Re: MC front end to PostgreSQL
Pierre Andu , andu a écrit : When it comes to browsers they should be considered bugged when they work... I'd like to understand why people use javascript when they can do with plain html. Allo Andu, I agree with you. Most browser-side problems are happening in parsing ..js code. Sorry folks, but I totally disagree with you... Yes, parsing JS can be a problem sometimes (especially between the same browser version running on different platforms), but according to my humble experience, HTML is much worse !!! JS + CSS (actually DHTML) is the less painful solution... Unless of course, your use of HTML is limited to forms... As for Flash, I just can't understand why most ppl fall in love with it... It's a totally self-contained environment that can't interact with anything else on your webpage... Furthermore, the scripting language is the most absurd thing I've ever seen (although I must confess I don't have a long experience with it : what I mostly do is trying to write a few lines of script to help our graphic designer when he's facing a critical situation); for instance, I never managed to create a global variable in Flash... Telling the truth, I'm seriously thinking of using SVG in the future, coz I like the way it can be embeded in webpages and interact with JS. And BTW did anyone notice that SVG has been recommended by the W3C, and that they never mentioned Flash ? Last but not least : as for web-dedicated MC apps, I'm working on a rather ambitious project that would combine cgi, DHTML and MC (and a few other techniques). The problem is with our client (and even with many ppl in the company I'm working for) : the shift in the approach is so big that they need a long time (much more than I expected actually) to get used to it, before they take any decision... The funny thing is that the main reason for the client to take the plunge is when I say that in the long run, development costs will be reduced (and in my company, it's the opposite : it's a good reason to ignore my project and stick to the good old webpages)... JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Web-Dedicated Metacard
So, what kinds of strategies can anyone suggest to take this beyond the consensus reality barrier? Start with the unparalleled interactivity performance of REAL software like MetaCard, versus mere web-browser based access to HTML + JavaScript. For example: once the web page is rendered, can you move things around? *NO*. It's a fundamentally static interface. With MC, OTOH, you can move things around at will, do drag-and-drop, view [scripted] object-oriented drawings and animations, trap all keyboard keys, have a custom menubar, update other stacks relationally ... Try doing any of this with the all-too-popular web-based HTML + JavaScript stuff! The answer is typically Well, that's nice, but you are not going to reach as many people... It all depends on your marketing strategies and tactics, methinks. Adobe Acrobat pulled it off, didn't they! Look at it thir way. Provide the Reader freely. People DL it once and forget it. When you click on a .pdf link in the Web, the PDF document is automatically opened with the Acrobat Reader program/plugin. Simple. Still very web-based given that its still going on in the vicinity of your familiar web-browser (e.g. argument to placate your detractors). Same goes for MetaCard! You can auto-DL stacks on the fly ... If you don't tell em it's MC, the users will probably think that you are providing them with high-performance Java applets! ;-) How many are going to download your plugin? Download the player once, forget thereafter; your web experience, while remaining familiar, will be immensely more stimulating, interactive, and so on, and so on ... than ever before. Here's a further idea to make it even simpler: you might want to design into your stacks the ability to automatically and transparently contact your server in order to auto-update itself whenever necessary e.g. instead of pestering the user to manually update on a periodic basis like many programs/plugins do. You still have to get them to go via a browser and download your stuff... This is a spurious argument, especially given my above suggestions. Besides, you could also use your custom MC-clients as web-savvy programs that the user may not even know is a web program. Imagine for a moment, as I do, a widely distributed network of MC clients and servers acting as one collective distributed entity. Or, more usually, imagine what this could do for your LAN and/or Intranet. Why not just put it up in html in the first place. With HTML, content, content-structure, presentation and interactivity are all intertwined. The least they could do for flexibility and inter-operability is to code the content with XML. In which case, you also have to deal with the CSS and some other related W3C technologies and standards. In which case, it's more complicated to do it this way than the xCard way, and far less *reusable*. In stack form, you can output your content as HTML, XML, in database format, as a CGI, and so on. It's time for all xCards to show their colours and take their right-honorable-place on the podium of excellence, and consequently somewhat displacing the lowest-common-denominator that we have grown used to since 1995, but all for the better! Persuaded yet? ;-) Alain Farmer xCard fanatic PS: I should probably mention that in addition to all of the above, the Java version of FreeCard will be able to be embedded into web-pages in the same manner that Java applets are. No separate program or plugin; the stack in a portion of the web-page. Or vice-versa, I am told, so that we will be able to browse the web inside a widget of the stack's interface. Yup! the web from *within* a stack. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
--On Thursday, December 19, 2002 22:36:42 + jbv [EMAIL PROTECTED] wrote: Pierre Andu , andu a écrit : When it comes to browsers they should be considered bugged when they work... I'd like to understand why people use javascript when they can do with plain html. Allo Andu, I agree with you. Most browser-side problems are happening in parsing ..js code. Sorry folks, but I totally disagree with you... Yes, parsing JS can be a problem sometimes (especially between the same browser version running on different platforms), but according to my humble experience, HTML is much worse !!! JS + CSS (actually DHTML) is the less painful solution... Unless of course, your use of HTML is limited to forms... Aren't we all saying the same thing though, just looking from different angles? In my case JS can and does crush Opera on Linux i386 but it does fine on Mac, html doesn't crush ever but it can look like shit in older browsers as to css when it works it's nice but sometimes things overlap and it's a mess. Sometimes on one platform or another the page is just blank. With Macromedia stuff I have a problem to begin with (am I difficult??). Depends which mess you prefer. As for Flash, I just can't understand why most ppl fall in love with it... It's a totally self-contained environment that can't interact with anything else on your webpage... Furthermore, the scripting language is the most absurd thing I've ever seen (although I must confess I don't have a long experience with it : what I mostly do is trying to write a few lines of script to help our graphic designer when he's facing a critical situation); for instance, I never managed to create a global variable in Flash... Telling the truth, I'm seriously thinking of using SVG in the future, coz I like the way it can be embeded in webpages and interact with JS. And BTW did anyone notice that SVG has been recommended by the W3C, and that they never mentioned Flash ? Last but not least : as for web-dedicated MC apps, I'm working on a rather ambitious project that would combine cgi, DHTML and MC (and a few other techniques). The problem is with our client (and even with many ppl in the company I'm working for) : the shift in the approach is so big that they need a long time (much more than I expected actually) to get used to it, before they take any decision... The funny thing is that the main reason for the client to take the plunge is when I say that in the long run, development costs will be reduced (and in my company, it's the opposite : it's a good reason to ignore my project and stick to the good old webpages)... Side with the client;-), MC solutions are so much more reliable and in my case the client ends up wanting more not less so the money is the same just better spent. JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Dumb sort question - Tanks Comments
Thanks for checking... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: jbv [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 2:57 PM Subject: Re: Dumb sort question - Tanks Comments Ken, Sorry for being so late on this topic, but last week has been sort of hectic... Anyway, thanks a lot for your suggestion. I found the time to test it today : it works great but, like the other script submitted by Jacqueline, it becomes rather slow when the amount of data gets large... Best regards, JB jb, I'm sorry that I came in late on this, but here's a way to do it with a custom transposing function... it may not be fast enough, but adapt it to your data and give it a try and let us know your results: on mouseUp -- A sample line number to extract put 3 into theLineToGet put 1 into theItemNumberToSortBy -- Some sample data put b,d,c,a cr 2,4,3,1 cr B,D,C,A cr 20,40,30,10 into tVar -- Transpose the data put transposeIt(tVar) into temp -- Sort it sort lines of temp by item theItemNumberToSortBy of each -- extract line (column) of data, put it into a field put line theLineToGet of transposeIt(temp) into fld 1 end if end mouseUp function transposeIt what -- assumes comma-delimited items and cr-delimited lines put into returnVal put 1 into tItemCounter repeat for each line tLine in what put 1 into tLineCounter if tItemCounter = 1 then -- use replace for quick action on first line of data replace , with cr in tLine put tLine into returnVal else repeat for each item i in tLine put , after line tLineCounter of returnVal put i after line tLineCounter of returnVal add 1 to tLineCounter end repeat end if add 1 to tItemCounter end repeat return returnVal end transposeIt Hope this helps, Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: jbv [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 08, 2002 9:36 AM Subject: Re: Dumb sort question - Tanks Comments Thank you all for your help suggestions. Unfortunately, none of them helped solving my problem... Below you'll find a few more info on what I'm trying to do, comments on some suggestions and finally some feature requests for future versions of MC. Basically, I need to sort a variable featuring 5 lines with a max of 30,000 items each. The sort key could be any of the 5 lines, and after sorting I'd like to extract any line of the variable (get line 3 of myVariable) for further processing. The content of every item of every line can change / evolve continuously. When the variable is organized as 30,000 lines of 5 items each, sorting is a snap (less than 1 second), but then extracting 1 column is impossible... Jacqueline : Thanks for your script : it works great, but when the variable reaches 20,000 items per line, it becomes way too slow... Ray : Yes, the transpose function looks attracting, but unfortunately it only works on arrays. And once the array has been transposed, it seems impossible to extract 1 single line / row. I tried to put the array content into a variable, but it remains stractured as an array... BTW, when the size of a 2 dimensions array reaches a certain limit (5 rows 20,000 column), I get the error message : can't transpose this array (or something similar), while it works fine with 5 rows and 10,000 colums... Is it a bug ? Mr X : Yes, 1 of the Rinaldi externals does that perfectly, but doesn't run on Windoze... Andu and Tariel : Yes, being able to access arrays content via individual rows columns would be a GREAT feature... I'd even dare to say that future versions of MC should implement most of the properties functions associated with spreadsheets in OMO, but applied to arrays, which means : - the ability to split arrays vertically horizontally - the ability to extract individual rows / colums - the ability to sort the content of an array according to sort keys that could be individual rows / colums - a special find function that would work like in OMO spreadsheets : find rows of myTab where item 2 10 would return a comma-separated list of numbers of rows for which this condition is true Actually, spreadsheets in OMO where 1 of the greatest tools I've ever used and I still miss them several years later... Of course, this would work on 1 or 2 dimension arrays; for 3 dimension
Re: Web-Dedicated Metacard
Sannyasin Sivakatirswami wrote: I changed the thread on this because I am also following the MC--PostGreSQL closely in its own right... OK, so agreed, we can use Metacard to provide content over the web. I am doing it already in a very small way... but let's we discuss this in a larger context (we got 1.7 million visitors on just three of our domains in 2002... those are visitors, not hits) If one broaches the subject of putting in time to develop content for MC based delivery, saying I can get 20 times the content ready for delivery in the same time it would take to get 1 unit of content out via HTML. (I just spend a month of my time with another team member getting one book on line as HTML... amazing amount of human resources required to do such a simple thing.) The answer is typically Well, that's nice, but you are not going to reach as many people... how many are going to download your plug in? You still have to get them to go via a browser and download your stuff... why not just put it up in html in the first place. So, what kinds of strategies can anyone suggest to take this beyond the consensus reality barrier? One usability argument is at: Beyond the Browser Rediscovering the Role of the Desktop in a Net-centric World http://www.fourthworld.com/embassy/articles/netapps.html For public sites there are admittedly few compelling reasons to counter the confusion factor with helper apps (keeping in mind that 100 is an average IQ). For intranets, however, there are many compelling arguments. Perhaps the most significant is the $1 billion in productivity lost to US corporations to employees doing random Web surfing. MC provides a way to build network-distributable content that is richer than the Web, can be more cost-effective, and provides a focus limited to whatever the stakeholders want. There's also an argument for specialized content beng delivered to focused public audiences, which will be evidenced in a modest lil' gadget I'll be making available by Christmas eve -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.1: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Yo troops, With all this talk about the pleasures of working with HTML, I just couldn't resist sending this along... -- HOW TO BUILD A WEB PAGE IN 25 STEPS 1. Download a piece of Web authoring software ~ 20 minutes. 2. Think about what you want to write on your Web page ~ 6 weeks. 3. Download the same piece of Web authoring software, because they have released 3 new versions since the first time you downloaded it ~ 20 minutes. 4. Decide to just steal some images and awards to put on your site ~ 1 minute. 5. Visit sites to find images and awards, find 5 of them that you like ~ 4 days. 6. Run setup of your Web authoring software. After it fails, download it again ~ 25 minutes. 7. Run setup again, boot the software, click all toolbar buttons to see what they do ~ 15 minutes. 8. View the source of others' pages, steal some, change a few words here and there ~ 4 hours. 9. Preview your Web page using the Web Authoring software ~ 1 minute. 10. Try to horizontally line up two related images ~ 6 hours. 11. Remove one of the images ~ 10 seconds. 12. Set the text's font color to the same color as your background, wonder why all your text is gone ~ 4 hours. 13. Download a counter from your ISP ~ 4 minutes. 14. Try to figure out why your counter reads You are visitor number 16.3 E10 ~ 3 hours. 15. Put 4 blank lines between two lines of text ~ 8 hours. 16. Fine-tune the text, then prepare to load your Web page on your ISP ~ 40 minutes. 17. Accidentally delete your complete web page ~ 1 second. 18. Recreate your web page ~ 2 days. 19. Try to figure out how to load your Web page onto your ISP's server ~ 3 weeks. 20. Call a patient friend to find out about FTP ~ 30 minutes. 21. Download FTP software ~ 10 minutes. 22. Call your friend again ~ 15 minutes. 23. Upload your web page to your ISP's server ~ 10 minutes. 24. Connect to your site on the web ~ 1 minute. 25. Repeat any and all of the previous steps ~ eternity --- Ain't technology wonderful? Ray G. Miller --- Turtlelips Productions 4009 Everett Ave. Oakland, CA 94602 MailTo:[EMAIL PROTECTED] (V) 510.530.1971 (F) 510.482.3491 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
xCards versus HTML
If we talk about public web sites the goal should be absolute accessibility everywhere. I think we can all agree on this fundamental goal. But making a player available freely and providing content which is not html-ized does not contravene this crucial principle. You cannot create xCard content with a plain old text editor (W3C's definition of accessibility) but no-cost versions of MC and RunRev are available via the web which allow you to do everything that HTML can do, with no limitations; script the interactivity of your content with the 10-line and 25-line scripting-limits of MC and RunRev respectively. Much can be achieved within this constraint given that the script of buttons rarely exceed a few lines, for example. Full accessibility, in my view, should also take into consideration the ease with which the content and its interactivity can be maintained/modified by those who create the wares AND by those who USE them too. What would you rather work with? With an xCard that allows you to build your web solutions with a WYSIWYG GUI vs a traditional approach to web solutions which requires you to *textually* code the content, its structure and the appearance that its *likely* to have on the client side, plus your users cannot readily change it themselves. Do you prefer xTalk over JavaScript? Unfortunately as long as somebody is going to make a buck out of it, html will never evolve and the public will be served only half. The HTML standard has been retired from the development cycle. IOW, W3C has officially declared that the HTML standard is done. It won't evolve any further. W3C others are now promoting XML (and kin) as the standards of the future. At best, HTML will live on as xHTML, IOW as a dialect of XML that can be handled by XML as XML. The excuse that the backward compatibility will suffer is false, people do upgrade when they have a reason. Backward compatibility is important but in the ebullient and volatile climate of rapid technological changes that we live in these days, its not always feasible. To avoid this merry-go-round, we must endeavour to make our wares (and the underlying code) as OPEN as possible. Open to third-party enhancements, as well open to the subsequent changes that will inevitably be made to the ware/code. This, in turn, is mainly a question of good design and a bit of foresight. Backward compatibility is more viable (sustainable) with stacks than with HTML pages. A stack is equivalent to a complete site, yet far more flexible than the dozens or hundreds of corresponding web pages. A stack can/will be scripted to re-purpose the existing content, casting the content in several forms: HTML, XML, textfiles, database records, reports, CGI program; individually, or any mix that you wish. New formats can also be scripted as they become available, relevant, popular... without fussing with the content at all and without disrupting the other formats either. I agree with you that people do upgrade when they have a good reason and a reasonable of success. It's evolution! My conviction is that we have the upper-hand in terms of potential, but I suppose that we the xCard community has not made its case persuasively enough. Not yet that is! Ignorance of the superiority of our xCard approach must be countered with more communication, and hopefully my last 3 messages to this list have contributed to this, albeit in a very small way. You can quote my ramblings, if you wish, in other forums. As it is, I am preaching to the converted, eh! For those of you who know me better, I am endeavouring to persuade the university-based RD center that I work for to switch over to an xCard approach from a PHP+SQL solution which mirrors what everyone else is doing. No thank you; conformity sucks!, particularly when one is being pressured to conform to something mediocre like HTML and JavasScript. We can, and will do, much better than this. Update : my colleagues and my superiors are taking my proposal very very seriously. They expect me to submit a detailed plan along these lines, in order to fetch some top-notch support, including some funding, to pursue this xCard approach *aggressively*. :-) I can't believe how much time I have blown on this post. I have to get back to work now. If I am boring you all, then please tell me eh! ;-) Editorially yours, Alain Farmer Laboratoire de Communautique Appliquée Université de Québec à Montréal (UQAM) [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
andu wrote: --On Thursday, December 19, 2002 10:42:11 -0800 Scott Rossi [EMAIL PROTECTED] wrote: IMO, HTML has evolved; look at all the spinoffs: DHTML, XML, SMIL, etc. The bigger problem is (lack of) standards. You just mentioned a few, the even bigger problem seems to be sticking to just one ;-). No doubt we are moving that direction with HTML specs, etc, but it's interesting to note that free competition has worked to our disadvantage in this area: while each browser technology attempts to out-feature the other, developers are left having to create workarounds to make their pages accessible everywhere. The original promise of the Web (write once, read anywhere) has been grossly unfulfilled and even undermined by competition. Exactly my point, competition is about money and power not quality. Agreed and along that, my clients have'nt to care about the details that make, for example, them unable to post data to the servers because the misconfigured browser, because the forgotten password,... that make them unable to print readables reports from the web pages (even when i offer to them the htmldoc online utility that let them display on the fly the webpages as PDF outputs). Because my master clients don't want to let the reports writers spend to much time in web datas reporting tasks, they are ok to pay to have the best doables tools even if Netscape or Explorer have to be replaced by fine home-made web conectables multimedia front-ends. Speaking as someone who has faced these issues for years, I am quite tired of dealing with them and am more than ready to embrace a technology that makes my life easier instead of harder, whether it's Javascript, Flash, or a MetaCard/Web implementation. You're probably be right that someone is making a buck somewhere, but IMO it's at the expense of those folks trying to build sites for a living. Me? Bitter? No... :-) Alone? Hardly.;-) Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard -- Cordialement, Pierre Sahores Inspection académique de Seine-Saint-Denis. Applications et bases de données WEB et VPN Qualifier et produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: xCards versus HTML
Backward compatibility is more viable (sustainable) with stacks than with HTML pages. A stack is equivalent to a complete site, yet far more flexible than the dozens or hundreds of corresponding web pages. A stack can/will be scripted to re-purpose the existing content, casting the content in several forms: HTML, XML, textfiles, database records, reports, CGI program; individually, or any mix that you wish. New formats can also be scripted as they become available, relevant, popular... without fussing with the content at all and without disrupting the other formats either. I agree with you that people do upgrade when they have a good reason and a reasonable of success. It's evolution! My conviction is that we have the upper-hand in terms of potential, but I suppose that we the xCard community has not made its case persuasively enough. Not yet that is! Ignorance of the superiority of our xCard approach must be countered with more communication, and hopefully my last 3 messages to this list have contributed to this, albeit in a very small way. You can quote my ramblings, if you wish, in other forums. As it is, I am preaching to the converted, eh! Hmm, you seem to forget one little detail. MC is not a stagnant environment and evolves as well, creating compatibility issues of its own as new versions are coming out. A trivial example of something very real (I ran into this myself just recently): if you happen to use 2.4.3 and use the slash constant that it supports, your stack won't work correctly with 2.4.1. Will you expect everyone to upgrade to the newest MC always? This is equivalent of asking everyone to abandon Netscape 4.x and move to 7 (I think they are still more people using 4.x than 7). The bottom line: things are not that trivial in wide open world :) Ronert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: HTML versus xCards
Hello Ray and y'all, Yo troops, Nice of you to join in! ;-) With all this talk about the pleasures of working with HTML, I just couldn't resist sending this along... HOW TO BUILD A WEB PAGE IN 25 STEPS... Hilarious but true! ;-) Playing devil's advocate for a moment, it could be argued that most of these site-building steps apply whether it's a web site or not. Selecting the images, for example. Moreover, my approach of creating a stack to update and manage an entire web site, given that it is generating the HTML of a web site, is even more work than just putting together the same site without this site [re-]generator, but the advantages of this extra work pay off big dividends when [unpredictable] changes need to done, in terms of content as well as appearance and structure. With the stack, changing the bg image of all of the pages is as simple as changing the content of one field (type it in and/or a browse button) and then clicking on the Regenerate this site btn. Very fast, very effective, no multiple pages to change, no risk of human-error ... Pure joy! And this is just an example, among countless examples, of the power of managing and generating HTML with an xCard. The web-savvyness of the xCards (with an XCMD in HC/SC) pays off here because it means that the generated web-pages can automatically be sent (via FTP, HTTP) to the remote the server that hosts your web site (e.g. if and when you are not your own web server). So, as you can see, it's not necessarily a matter of completely replacing HTML with an xCard. And no hard choices to make, either, because you can have BOTH at the same time. :)) I am really enjoying this thread, Alain Farmer __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: xCards versus HTML
Hello Robert and y'all, Hmm, you seem to forget one little detail. MC is not a stagnant environment and evolves as well, creating compatibility issues of its own as new versions are coming out. A double-edged sword indeed. On the one hand, we want development in order to improve what we have already got (evolution). OTOH, we want terrain-tested stability and reliability that won't break existing works (backward compatibility). Reality, so to speak, is somewhere in between these two extremes. Don't get me wrong, however: you're making a very good point. Regards, Alain Farmer __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re:Subject: Web-Dedicated Metacard
Message: 3 Date: Thu, 19 Dec 2002 08:17:01 -1000 Subject: Web-Dedicated Metacard From: Sannyasin Sivakatirswami [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] I changed the thread on this because I am also following the MC--PostGreSQL closely in its own right... OK, so agreed, we can use Metacard to provide content over the web. I am doing it already in a very small way... but let's we discuss this in a larger context (we got 1.7 million visitors on just three of our domains in 2002... those are visitors, not hits) If one broaches the subject of putting in time to develop content for MC based delivery, saying I can get 20 times the content ready for delivery in the same time it would take to get 1 unit of content out via HTML. (I just spend a month of my time with another team member getting one book on line as HTML... amazing amount of human resources required to do such a simple thing.) The answer is typically Well, that's nice, but you are not going to reach as many people... how many are going to download your plug in? You still have to get them to go via a browser and download your stuff... why not just put it up in html in the first place. So, what kinds of strategies can anyone suggest to take this beyond the consensus reality barrier? I have to deliver data to a large audience. This data is : 1000 pages of text 1 pictures + caption I want these data to be accessible through search engines like google or altavista for schools with low end or old computers. I also need for some institutions to deliver the same data on a cd-rom or on a local ethernet network. I decided to deliver this data as html for 2 reasons : 1) if my data is pure html, it can be searched through google or altavista ; it means that my 1000 pages, 1 captions and 1 captions are available for everyone on the web. If i put my data in a database or a stack and deliver it through some server-side software, it will be available only to people connected to my web-site, not to people searching for informations. 2) my data are readable without plugin on low end or old computers. The efficient way for me is to program an metacard application for me to edit the data. Does not matter if the text data are stored as fields, custom props, text files, xml files or in an interfaced database (in fact at this time i use text files or xml files). The main fact is that the data is batch-edited in metacard. I can for example export my data as a tagged text, make an orthographical and grammatical correction in Word and get the data back. I can build indexes, make hyperlinks... Of course the pictures are in external files. But i can with metacard sort the pictures by size, make most of the works of resizing and jpeg compression, etc... From this editor oriented metacard app, it is very easy and fast to build either a user oriented metacard app to be delivered on cd-rom or on a local network ; it is also very fast and easy to build html pages. I prepare html templates and metacard mixes the templates with the data. As long as i need an click and go interactivity, this way is perfect. *** I would use a server-side metacard app only if i had to make transactions with the user. For example if i want the user to be able to add new texts or new pictures to my data, or if i had to deliver to the user personalized data. *** When i need user-side interactivity, i can not work with metacard as long there is no web-plugin for metacard. So i have no other choice than working with javascript or flash, but that's an other story... Claude Lemmel / Opus species ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
LOL! That's beautiful... something I think I'll post in my office! Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: Ray G. Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 5:08 PM Subject: Re: MC front end to PostgreSQL Yo troops, With all this talk about the pleasures of working with HTML, I just couldn't resist sending this along... -- HOW TO BUILD A WEB PAGE IN 25 STEPS 1. Download a piece of Web authoring software ~ 20 minutes. 2. Think about what you want to write on your Web page ~ 6 weeks. 3. Download the same piece of Web authoring software, because they have released 3 new versions since the first time you downloaded it ~ 20 minutes. 4. Decide to just steal some images and awards to put on your site ~ 1 minute. 5. Visit sites to find images and awards, find 5 of them that you like ~ 4 days. 6. Run setup of your Web authoring software. After it fails, download it again ~ 25 minutes. 7. Run setup again, boot the software, click all toolbar buttons to see what they do ~ 15 minutes. 8. View the source of others' pages, steal some, change a few words here and there ~ 4 hours. 9. Preview your Web page using the Web Authoring software ~ 1 minute. 10. Try to horizontally line up two related images ~ 6 hours. 11. Remove one of the images ~ 10 seconds. 12. Set the text's font color to the same color as your background, wonder why all your text is gone ~ 4 hours. 13. Download a counter from your ISP ~ 4 minutes. 14. Try to figure out why your counter reads You are visitor number 16.3 E10 ~ 3 hours. 15. Put 4 blank lines between two lines of text ~ 8 hours. 16. Fine-tune the text, then prepare to load your Web page on your ISP ~ 40 minutes. 17. Accidentally delete your complete web page ~ 1 second. 18. Recreate your web page ~ 2 days. 19. Try to figure out how to load your Web page onto your ISP's server ~ 3 weeks. 20. Call a patient friend to find out about FTP ~ 30 minutes. 21. Download FTP software ~ 10 minutes. 22. Call your friend again ~ 15 minutes. 23. Upload your web page to your ISP's server ~ 10 minutes. 24. Connect to your site on the web ~ 1 minute. 25. Repeat any and all of the previous steps ~ eternity --- Ain't technology wonderful? Ray G. Miller --- Turtlelips Productions 4009 Everett Ave. Oakland, CA 94602 MailTo:[EMAIL PROTECTED] (V) 510.530.1971 (F) 510.482.3491 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
clipboard
Can anyone explain the following: Using Mac OS9: If you copy some text in a Metacard stack and while Metacard is still running, go into another application and paste, the text pastes. But if you copy some text in a Metacard stack, quit Metacard, then go into another application and paste, paste does not work. In Revolution, if you do the same thing, paste works in both cases. It seems Metacard empties the clipboard when it quits. Is this a bug? Is there a workaround? Thanks Fred Moyer ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC front end to PostgreSQL
Did you try Opera 5 (Andu said, previously, that Opera 6 linux is bugged) or, else Mozilla, whoses works fine there on both Linux and Jaguar ? I tried Opera, but was not satisfied with a thing that seemed to me as a crude unfinished port ;- Really -- I am pleased with the functionalities of iCab and overall ease of use. If only it could be not so touchy (chatouilleux) about html / javascript specs ;- And if only it completely dealt with CSS... -- Regards, (-8 Dominique ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
