Re: Cross-tab report: from list

[Alex Tweedly]

mfstuart wrote:

Hi all,

How do I manipulate the following data list into a spreadsheet (cross-tab
report) format?

I'm assuming arrays are in the works for this to build the spreadsheet data
set, 
but since I haven't worked with them, I'm not sure about that.


  
There is probably a faster way, or a more succinct way, using more 
complex arrays - but since you said you hadn't worked with arrays much, 
I kept the array use very simple.  Only tricky thing (I think) is the 
use of combine to convert the years array into a simple list (using the 
array eliminated duplicates easily).


This assumes that the output should include all years within the range- 
even if there was no data for that year. You could change that easily by 
changing the lines

  repeat with i = t1 down to t2
to
  repeat with j = (the number of lines in tYears) down to 1
 put word 1 of line i of tYears into i


on mouseUp
   local theData, theMonthNames, theYear, theMonth, theValue
   local firstValidYear, lastValidYear
   local tYears, tData, tOutput
   local W, t1, t2
   
   put empty into field "F1"

   put URL ("file:C:/Users/Alex/Documents/data.txt") into theData
   
   put "January February March April May June July August September 
October November December" into theMonthNames

   set the itemDel to "-"
   -- set the valid year range
   put 1900 into firstValidYear
   put 2009 into lastValidYear
   
   repeat for each line theLine in theData

  put item 1 of theLine into theYear
  put item 2 of theLine into theMonth
  put item 3 of theLine into theValue
  if theYear is not a number or theYear < firstValidYear or 
theYear > lastValidyear then

 put "Bad year " && theLine & CR after msg
 next repeat
  end if
  if theMonth is not among the words of theMonthNames then
 put "Bad month " && theLine & CR after msg
 next repeat
  end if
  if theValue is not a number then
 put "Bad value " && theLine & CR after msg
 next repeat
  end if
  
  -- add this to the list of years

  put true into tYears[theYear]
  
  -- and store the value

  put theValue into tData[theMonth, theYear]
   end repeat
   
   -- now put the years into a list, and sort it

   combine tYears by CR and TAB
   sort tYears  numeric by item 1 of each
   
   -- and create the output

   put "month" & TAB into tOutput
   put word 1 of line -1 of tYears into t1
   put word 1 of line 1 of tYears into t2
   repeat with i = t1 down to t2
  put i & TAB after tOutput
   end repeat
   -- delete last trailing TAb and add a newline
   put CR into char -1 of tOutput
   repeat for each word W  in theMonthNames
  put W & TAB after tOutput
  repeat with i = t1 down to t2
 if (W & Comma & i) is among the keys of tData  then
put tData[W, i] & TAB after tOutput
 else
put "0" & TAB after tOutput
 end if
  end repeat
  put CR into char -1 of tOutput
   end repeat
   put tOutput into msg
end mouseUp

Hope this helps - feel free to ask if anything is unclear.

-- Alex.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev cgi & mySQL (again)

[Brian Yennie]

I'm a huge fan of practical solutions, and this approach is definitely  
a good one if you are never going to be dealing with millions of  
records. Modern processing can do an awful lot without a "real"  
database muddying things up.


The only thing I would add is that if you ARE going to deal with  
really large data sets, the only real option is to re-factor your data  
with a database in mind. A well designed SQL database can definitely  
handle much larger sets of data much faster than Rev because it scales  
better for these tasks. That's not a knock on Rev it's simply what a  
database is designed to do. However, it make take an upfront  
investment is rethinking how you approach and structure your data.


I'm with you on that - use what one knows of mysql to get a bulk  
data block,
then use chunk expressions to further parse  I used to feel  
guilty that
I didn't do it all in MYSQL, using views and other tricks, but these  
days

I'm ok with it.


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev cgi & mySQL (again)

[stephen barncard]

I'm with you on that - use what one knows of mysql to get a bulk data block,
then use chunk expressions to further parse  I used to feel guilty that
I didn't do it all in MYSQL, using views and other tricks, but these days
I'm ok with it.

On Fri, Jan 2, 2009 at 6:31 PM, Sarah Reichelt wrote:

> I have done a similar thing in the past due to my lack of expertise
> with SQL. I did an initial SQL query to get set of data that included
> all that I needed but had more. That gave me a variable (I didn't use
> files) which I processed further using Revolution. This was very fast
> however an SQL expert might have been able to do the same thing in
> pure SQL. I tend to think that the server connection is most likely
> the slowest part of the operation, so any method that reduces the
> amount of data to be transmitted is a good thing. But this has to be
> balanced against processing times.
>
> Anyway my advice is to benchmark the different approaches and see what
> works best in your particular circumstance.
>
> Cheers,
> Sarah
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 
Stephen Barncard
-
San Francisco
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev cgi & mySQL (again)

[Brian Yennie]

JB,

If you are interested (and able to share), send me a dump of your  
database off-list. I do a lot of MySQL work and although what you are  
doing may be a design limitation, I'd be willing to fiddle with it for  
a few minutes, which is infinitely more productive than speculating in  
emails =).


- Brian


Hello again,

For those interested in the latest episodes of my struggle with mySQL,
here's a summary : I've tried the MATCH (col1) AGAINST ("word1 word2")
construct, and it's blazing fast (roughly 50 to 100 times faster  
than my previous

queries full of OR statements...
But there's a couple of drawbacks : columns on which MATCH.. AGAINST  
is
used need to have a fulltext index attached to them (which is  
logical), BUT there's
a minimum word length limit on such indexes (default length is 4,  
set with a mySQL

global). No wonder it's so fast, since lots of words are ignored...
So, if you need smaller words to become searchable, you need to  
modify the
ft_min_word_len global (setting it to 1 if you need all words to be  
searchable) and

restart mySQL... and reconstruct your indexes as well.
And then searches via  MATCH ... AGAINST become almost as slow as  
regular

SELECT searches...

Oh, and I forgot to mention that there's also a list of rejected  
words that can be modified

in another global...

JB

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev cgi & mySQL (again)

[jbv]

Hello again,

For those interested in the latest episodes of my struggle with mySQL,
here's a summary : I've tried the MATCH (col1) AGAINST ("word1 word2")
construct, and it's blazing fast (roughly 50 to 100 times faster than my 
previous
queries full of OR statements...
But there's a couple of drawbacks : columns on which MATCH.. AGAINST is
used need to have a fulltext index attached to them (which is logical), BUT 
there's
a minimum word length limit on such indexes (default length is 4, set with a 
mySQL
global). No wonder it's so fast, since lots of words are ignored...
So, if you need smaller words to become searchable, you need to modify the
ft_min_word_len global (setting it to 1 if you need all words to be searchable) 
and
restart mySQL... and reconstruct your indexes as well.
And then searches via  MATCH ... AGAINST become almost as slow as regular
SELECT searches...

Oh, and I forgot to mention that there's also a list of rejected words that can 
be modified
in another global...

JB

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Large databases kaput?

[dunbarx]

J...

OK, got it. I will cross that bridge when I come to it.

Thanks,

Craig


On Jan 3, 2009, at 1:59:04 PM, "J. Landman Gay"  
wrote:
From:   "J. Landman Gay" 
Subject:Re: Large databases kaput?
Date:   January 3, 2009 1:59:04 PM EST
To: "How to use Revolution" 
dunbarx wrote:
> Thanks for the reply, but not that. I heard on another thread that there 
> was a Rev issue with large stacks, 5000+ cards. I wanted feedback before 
> I made a test stack to check it out. Is it a matter of navigation, 
> finding stuff, open/close or what?

As Bjoernke mentioned, it's mostly a question of speed. Rev doesn't have 
HC's hintbits (and can't; it is proprietary info) and so searches need 
to look at every text block to accomplish a find. If your stack doesn't 
rely on "find" (or you don't mind waiting) then you can get away with 
much larger stacks. If you need to navigate to a particular card 
quickly, creating your own index using card IDs is the fastest way to 
manage it. Card IDs are faster than any other type of card access.

Rev is entirely RAM-based, so if your stack is tens of megabytes in size 
it will take longer to load it all than a smaller stack. If you do not 
have enough available RAM to hold the entire contents, speed will also 
be affected by the required disk paging to virtual memory.

The 5000 card number is a very gerneric estimate only. A stack with a 
single field on each card can remain responsive even with many more 
cards than that. If each card has many fields, the number is lower. I've 
had stacks with ~8000 cards that worked okay (though a bit sluggishly) 
because each card shared a background with only 2 fields containing very 
little data.

If you have a specific stack in mind, I'd say to convert it and see how 
it does. Each one will behave differently depending on the objects on 
the cards and how you need to navigate.

-- 
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Revolution Online

[Richard Gaskin]

revinfo1155 wrote:


Does Rev have anything like tilestack? Is there a way to run stacks online?


TileStack is a HyperCard-to-HTML/CSS/JavaScript translator.  I've long 
advocated that approach for Rev work, and with cool frameworks like 
Apple's SproutCore it seems a great many others are thinking along 
similar lines for all sorts of app development:





Since JavaScript is the only language built into web browsers, it's the 
only way to run applications truly natively there.  Everything else 
requires Java or a plugin.


RunRev Ltd. has announced plans to do the latter, making a browser 
plugin that will actually run stacks inside of a web page:




It sounds cool as far as plugins go.  No specific release date has been 
given at this time; maybe Kevin can chime in here with a status update.


In the meantime, I've been porting some Rev stacks to the web with my 
own custom HTML/CSS/JS converters.  Much of the work requires 
hand-translating code, but automating the translation of layouts is a 
snap, so it can be a great option for content-rich stacks.


It never hurts to know more than one language, and JavaScript is by far 
the most popular scripting language in the world.  It's ugly as sin in 
parts, and sometimes just kinda dumb, but it's not like there's any 
choice for writing native browser apps so you don't have to fret over 
whether you've made the right decision in using it. :)  But your 
patience with learning JS is well rewarded by letting you play with CSS, 
and the more you play with CSS the more you'll miss its absence in Rev.


--
 Richard Gaskin
 Fourth World
 Revolution training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Losing data when quitting

[J. Landman Gay]

Peter Brigham wrote:

On Jan 2, 2009, "J. Landman Gay"  wrote:


..
On the other hand, I wish there were some way to get Rev to *stop*
asking me to save. I have some utility stacks with text display fields,
but the text is temporary and I never want it saved. But every time I
close the stack, Rev bugs me about saving changes. I now only open those
stacks in the MetaCard IDE, where it leaves me alone.



Wouldn't setting the cantmodify of the stack to true do it for you? A 
bit of a pain if you are still tweaking the thing, since you can't edit 
scripts or adjust controls without setting the cantmodify back to false, 
but for a utility that is tried and true and is just being used a a 
tool, this works for me.


Yes, that works. I guess I'll have to resort to that if I want to use 
Rev with these stacks.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Losing data when quitting

[J. Landman Gay]

Paul Looney wrote:

JLG,
Do you recall the bug number? Maybe we could get some new votes.


I never really looked to see...but a search I just did indicates that 
bug 302 is the closest match (that shows you how old the bug is) and 
that one is marked "not a bug". It really isn't quite the same as we're 
describing but it's close. The issue at hand here is whether a focused 
field changes focus when a button is clicked. According to Scott Raney, 
no OS removes focus from a field when a button is clicked, so the 
current behavior is correct. I guess I agree with that.


The problem is that the IDE doesn't see a change in focus either, which 
results in the missing "save" dialog. Not sure how to handle this; maybe 
a new bug report would alert the team that a patch in the IDE is 
necessary for just this "save" issue. It won't change any problems the 
rest of us have with other scripts that rely on closefield -- for 
example, when changing cards. For those situations I usually do 
something like this in my scripts:


  on closeCard
   if the selectedfield <> ""
   then send "closefield" to the selectedfield
  end closeCard

Sometimes I need to put something similar into buttons or other places 
too, it all depends on the scripts I'm using. This handler isn't exactly 
correct though, because if the field content hasn't changed then sending 
a "closefield" message isn't always what you want.




Paul Looney
On Jan 2, 2009, at 5:44 PM, J. Landman Gay wrote:


Paul Looney wrote:

There may be other recipes as well, but the stack saving problem 
seems to be related to the lack of a closeField - which is not sent 
if the focus is still in the edited field when the stack is closed.


This is a really old bug, I remember working around it years ago. I've 
gotten so used to tabbing out of fields before I close a stack that I 
hardly ever see the problem any more. But that isn't a good solution 
for everyone.


On the other hand, I wish there were some way to get Rev to *stop* 
asking me to save. I have some utility stacks with text display 
fields, but the text is temporary and I never want it saved. But every 
time I close the stack, Rev bugs me about saving changes. I now only 
open those stacks in the MetaCard IDE, where it leaves me alone.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Large databases kaput?

[J. Landman Gay]

dunbarx wrote:
Thanks for the reply, but not that. I heard on another thread that there 
was a Rev issue with large stacks, 5000+ cards. I wanted feedback before 
I made a test stack to check it out. Is it a matter of navigation, 
finding stuff, open/close or what?


As Bjoernke mentioned, it's mostly a question of speed. Rev doesn't have 
HC's hintbits (and can't; it is proprietary info) and so searches need 
to look at every text block to accomplish a find. If your stack doesn't 
rely on "find" (or you don't mind waiting) then you can get away with 
much larger stacks. If you need to navigate to a particular card 
quickly, creating your own index using card IDs is the fastest way to 
manage it. Card IDs are faster than any other type of card access.


Rev is entirely RAM-based, so if your stack is tens of megabytes in size 
it will take longer to load it all than a smaller stack. If you do not 
have enough available RAM to hold the entire contents, speed will also 
be affected by the required disk paging to virtual memory.


The 5000 card number is a very gerneric estimate only. A stack with a 
single field on each card can remain responsive even with many more 
cards than that. If each card has many fields, the number is lower. I've 
had stacks with ~8000 cards that worked okay (though a bit sluggishly) 
because each card shared a background with only 2 fields containing very 
little data.


If you have a specific stack in mind, I'd say to convert it and see how 
it does. Each one will behave differently depending on the objects on 
the cards and how you need to navigate.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Revolution Online

[revinfo1155]

Does Rev have anything like tilestack? Is there a way to run stacks online?



Jack
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Large databases kaput?

[Björnke von Gierke]

The issue is speed of execution for card based operations, like push/ 
pop, find and so on. Making stacks that have such a big amount of  
cards is just not fast, even though things will work fine otherwise.


On 3 Jan 2009, at 18:05, dunbarx wrote:

Thanks for the reply, but not that. I heard on another thread that  
there was a Rev issue with large stacks, 5000+ cards. I wanted  
feedback before I made a test stack to check it out. Is it a matter  
of navigation, finding stuff, open/close or what?



--

official ChatRev page:
http://bjoernke.com/runrev/chatrev.php

Chat with other RunRev developers:
go stack URL "http://bjoernke.com/stacks/chatrev/chatrev1.3b3.rev";

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Large databases kaput?

[dunbarx]

Thanks for the reply, but not that. I heard on another thread that 
there was a Rev issue with large stacks, 5000+ cards. I wanted 
feedback before I made a test stack to check it out. Is it a matter of 
navigation, finding stuff, open/close or what?


Hence the "say it ain't so"

Craig Newman


On Jan 3, 2009, at 3:01:29 AM, "Nicolas Cueto"  
wrote:

From:  "Nicolas Cueto" 
Subject:Re: Large databases kaput?
Date:   January 3, 2009 3:01:29 AM EST
To: "How to use Revolution" 
Going out on a limb here...

If I understand you correctly -- namely,
you're trying to build a stack that has
5000+ cards -- then I think the problem
is not Rev's limitations but rather the
design you're envisioning for your stack.

Perhaps if you described a bit more what
you want your stack to do?

--
Nicolas Cueto
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Updating a stack

[Klaus Major]

Hi Philip,


Thanks for the reply Mark.

Can a stack that was created on a Mac PowerPC be opened on a Mac  
Intel?


Yes, stacks are processor independant.
And even platform independent, if you did not know yet ;-)


Philip Usher


Best

Klaus Major
kl...@major-k.de
http://www.major-k.de


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Updating a stack

[Philip Usher]

Thanks for the reply Mark.

Can a stack that was created on a Mac PowerPC be opened on a Mac Intel?

Philip Usher



on 1/2/09 10:24 PM, Mark Schonewille at
use-revolution-requ...@lists.runrev.com wrote:

Just open it. Choose Save As... from the File menu and make sure to
save the stack in the new format. You might want to check whether file
format preservation is turned on or off in the preferences.



On 2 jan 2009, at 19:23, Philip Usher wrote:

How might one go about updating a stack created in Revolution 1.1.1
in Mac OS 9 to the current version of Revolution on a Mac Intel?

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Flash + RevBrowser + Mac Problems

[Dave Cragg]

On 22 Dec 2008, at 20:03, Scott Rossi wrote:


Thanks to all the folks who responded about Flash & RevBrowser issues.
Perhaps there are differences between older and recent versions of
ActionScript, maybe the version of the Flash player is important, or  
maybe

there are idiosyncrasies due to the version of the underlying browser
mechanism (on OS X this is based on Safari/WebKit, yes?).  In any  
event, I
hope this is something that can be nailed down if we as developers  
want to

offer Rev + Flash solutions to clients/users.


Just another experience to add. (No solutions, sorry.)

This is with a Flash app built with Adobe's Flex. So no frame-based  
animation, and using ActionScript 3.


In IE, everything seems fine. In Safari in general, mouse interactions  
(button clicks, rollovers) work fine except with popup menus and  
lists. Clicking in a popup menu would most times result in the wrong  
item being selected, and it was impossible to scroll popup lists that  
had a scrollbar. I tried Brian's suggestion of setting wmode to  
opaque. This produced better results. However, none of the popups  
worked on the first time of opening. But on subsequent opening, they  
worked fine.


I think Flex's PopUp manager creates new Windows to draw the popups. I  
guess this points to Brian's idea that it is some kind of "window  
juggling" issue.


Cheers
Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Application Browser problem?

[Kurt Kaufman]

Scott and Mark,
Thanks for your replies.  So as not to confuse my daughter (and  
myself!), we will use script-based commands rather than the  
application browser.  There is also the added pedagogic benefit of  
reinforcing use of the message box!

RunRev really should fix this when they get around to it, though.

Kurt
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Application Browser problem?

[Mark Schonewille]

Hi Kurt,

I haven't used the Applicatiom Browser in years. I found it unreliable  
and decided to forget about it.


Whenever I want to copy a card to another stack, I type in the message  
box:


  copy this cd to stack "My Stack"

There is a request in the QCC to include "Copy Card" and "Past Card"  
in the Edit menu, but this request has been ignored so far. You can  
find the request at .


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com
http://www.salery.biz
Dutch forum: http://runrev.info/rrforum

We are always looking for new projects! Feel free to contact us to  
discuss your custom software project!


On 3 jan 2009, at 05:24, Kurt Kaufman wrote:

I'm helping my 12-year-old daughter learn to program with RunRev,  
and I couldn't really figure this one out:


Could someone point me to a reference on how to move cards reliably  
between stacks in the Application Browser?
I find I can't predict exactly how it will work, between "selecting"  
the card in the A.B. using the contextual menu (right-click),  
pressing COMMAND-C to copy (or menu Edit-->Copy Card), and then  
choosing a stack in which to paste the clipboard-held card.  (It  
seems that the Edit menu then offers "Paste Objects", rather than  
"Paste Card" as one might expect.)  At this point,
it seems that unless I either double-click on the destination stack  
in the A.B., or click in the destination stack's window, it is NOT  
selected for the paste function, **even though** I might highlight  
the desired destination stack by single-clicking it in the A.B..


So, I can be in a position of having a card on the clipboard, ready  
for pasting, and I highlight a card of the destination stack (all of  
it's current objects are displayed), and yet, since I have not  
actually **definitively** selected my destination stack, if I paste  
my card it will be pasted back into the source stack.



Sorry if this is detailed in the help files, and I'm just missing it.

Also: It seems there might be a refresh problem where a newly pasted  
card shows up in the stack window while the A.B. still shows the  
"pre-paste" card highlighted and no pasted card?  (After collapsing  
the destination stack in the A.B. and re-displaying it, it shows up  
correctly with the newly-pasted card.)


Thanks, Kurt

Rev 3.0.0, Build 750,  Mac OX 10.5.6



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Application Browser problem?

[Scott Morrow]

Hello Kurt,
Unfortunately I don't know the answer to your question about using the  
Application Browser... but can suggest an alternative. Using the  
Message Box (or a button script) you may control such copy and paste  
actions.


go card 2 of stack  "thisStack" -- or in the Application Browser you  
could go to card 2 by double clicking on it
copy card 7 of stack "thatStack" to stack "thisStack" -- will paste  
right after the current card in stack "thisStack"


Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   http://elementarysoftware.com/
email sc...@elementarysoftware.com



On Jan 2, 2009, at 8:24 PM, Kurt Kaufman wrote:

I'm helping my 12-year-old daughter learn to program with RunRev,  
and I couldn't really figure this one out:


Could someone point me to a reference on how to move cards reliably  
between stacks in the Application Browser?
I find I can't predict exactly how it will work, between "selecting"  
the card in the A.B. using the contextual menu (right-click),  
pressing COMMAND-C to copy (or menu Edit-->Copy Card), and then  
choosing a stack in which to paste the clipboard-held card.  (It  
seems that the Edit menu then offers "Paste Objects", rather than  
"Paste Card" as one might expect.)  At this point,
it seems that unless I either double-click on the destination stack  
in the A.B., or click in the destination stack's window, it is NOT  
selected for the paste function, **even though** I might highlight  
the desired destination stack by single-clicking it in the A.B..


So, I can be in a position of having a card on the clipboard, ready  
for pasting, and I highlight a card of the destination stack (all of  
it's current objects are displayed), and yet, since I have not  
actually **definitively** selected my destination stack, if I paste  
my card it will be pasted back into the source stack.



Sorry if this is detailed in the help files, and I'm just missing it.

Also: It seems there might be a refresh problem where a newly pasted  
card shows up in the stack window while the A.B. still shows the  
"pre-paste" card highlighted and no pasted card?  (After collapsing  
the destination stack in the A.B. and re-displaying it, it shows up  
correctly with the newly-pasted card.)


Thanks, Kurt

Rev 3.0.0, Build 750,  Mac OX 10.5.6


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Losing data when quitting

[Peter Brigham]

On Jan 2, 2009, "J. Landman Gay"  wrote:


..
On the other hand, I wish there were some way to get Rev to *stop*
asking me to save. I have some utility stacks with text display  
fields,

but the text is temporary and I never want it saved. But every time I
close the stack, Rev bugs me about saving changes. I now only open  
those

stacks in the MetaCard IDE, where it leaves me alone.



Wouldn't setting the cantmodify of the stack to true do it for you? A  
bit of a pain if you are still tweaking the thing, since you can't  
edit scripts or adjust controls without setting the cantmodify back to  
false, but for a utility that is tried and true and is just being used  
a a tool, this works for me.


Peter M. Brigham
pmb...@gmail.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

TLS

[David Bovill]

I'm programing a web service that specifies the use of TLS. From Wikipedia:

*Transport Layer Security* (*TLS*) Protocol and its predecessor, *Secure
Sockets Layer* (*SSL*), are cryptographic
protocolsthat
provide
security  and data
integrityfor
communications over
TCP/IP  networks such
as the Internet . Several versions of
the protocols are in wide-spread use in applications like web
browsing,
electronic mail , Internet
faxing,
instant messaging  and
voice-over-IP
(VoIP) . TLS and
SSL encrypt the segments of the Transport
Layerprotocols in use
for an end-to-end connection across the network. TLS is an
IETF  standards
track  protocol, last
updated in RFC 5246 , that was based on
the earlier SSL specifications developed by
NetscapeCorporation.

So this would seem to indicate that for coding purposes with Revolution TLS
and SSL are synonymous? Is there anything I shoud know about TLS rather than
SSL when trying to establish a connection to a server using the Rev SSL
libraries?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Losing data when quitting

[Timothy Miller]

Thanks Till,

Okay, I figured out how to reproduce.

It only seems to happen when I have another stack open, "underneath"  
the stack I've been concerned about. I'd forgotten about that.


I'll explain it this way:

bookstack.rev is the filename of a multi-card stack with several  
fields and buttons on each card, grouped, and behaving as a  
background. One field predominates. I'll call that bg field  
"bigfield"  I use bigfield like a text editor, sort of. A great deal  
of text gets typed into that field. The other fields and buttons are  
normally ignored. When I'm done with the stack, it would not  
necessarily occur to me to tab or click out of the field.


teststack.rev is the filename of a tiny stack, consisting of one card,  
one image and one button.


I haven't defined any stackfiles in either stack. Both reside in the  
same folder. (I don't know if that's relevant.)


Here's the replicable sequence of events. I doubt that all these steps  
are necessary to replicate the problem, but they are sufficient. The  
problem is slippery, in ways I can't completely pin down. Change  
certain minor steps and it goes away. But these steps always produce it:


--Make sure Rev is quit
--Launch bookstack.rev
--Close stack "revStartCentre," (It launches with Media.)
--Select the "browse" tool and close the "revTools" window
--Launch teststack.rev
--Click the title bar of Bookstack.rev to bring it to the front.
--Click a bg button that unlocks bg field "bigfield"
--Type some text into bg field "bigfield"
--Don't tab or click out of bigfield
--Select "Quit Revolution" from the menubar, or click on the small red  
"close" button, or choose "Close" from the "File" menu


Bookstack closes, without a "save' dialog, and the recently entered  
data is lost.
If I click or tab out of bigfield and then Quit Revolution, I do get a  
normal "save" dialog box.


This is starting to look like the issue Paul described in his first  
message on this thread, yesterday, mid-day.


I'm not quite sure whether this is already a well-known and reported  
bug.


For now, I think I'll place a "save and close" button on all my stacks.

I hope this is of some use to someone. At least confidence in my  
sanity is returning.


Cheers,

Tim



On Jan 3, 2009, at 12:49 AM, Till Bandi wrote:

If you edit that field and quit Rev your changes will not be saved  
(there will be no Save dialog).



Can't reproduce this. I get the save dialog.

Till Bandi

Am 02.01.2009 um 22:51 schrieb Paul Looney:


Tim,
I doubt it is your imagination - and I thank you for raising this  
issue again.
If you create a new stack and put two fields on it, you'll observe  
the following:

When you open the stack the focus is on the first field you created.
If you edit that field and quit Rev your changes will not be saved  
(there will be no Save dialog).
If you leave that field with by tabbing, or clicking elsewhere on  
the stack, or clicking into the second field, or using the Enter  
key - then you WILL be asked to save the stack on quitting.
There may be other recipes as well, but the stack saving problem  
seems to be related to the lack of a closeField - which is not sent  
if the focus is still in the edited field when the stack is closed.

Is this what you are seeing?
Paul Looney

On Jan 2, 2009, at 1:28 PM, Timothy Miller wrote:


Damn!

I replicated it several times this morning, with care.

Now I can't replicate it. I haven't changed anything.

I'll wait and watch, to see if it occurs again.

Tim

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev cgi & mySQL (again) -- Valentina Server have server side cursors

[Ruslan Zasukhin]

On 1/3/09 2:03 AM, "Bob Sneidar"  wrote:

Hi Bob,
Hi All,

> I have always toyed with the idea of writing a paging query system
> which paged through a large SQL database. The idea would be that you
> only have one live cursor but 2 or 3 "pages" (cursors) forward and
> back. As the user scrolls past the current page you silently swap the
> pointer to the current page, flush the farthest page back and query
> the next forward page. This would give the user the "appearance" of
> good performance paging through the data while minimizing the workload.

In fact if you will use Valentina Server, there is no need to break fingers
and head on a task which already solved :-)

In Valentina Server we offer both

* client side cursors (mySQL have only such)
* server side cursors

In nearest few months we will introduce also more improvements in cursor
navigation and client-side record caching.

--
TIPs:

For very complex queries that return unpredicted results in size, good are
server side cursors.

* This is better than using LIMIT. Because using limit you at least loose
information about HOW MANY records really was found. And you cannot show
then correct scrollbar.

* also server side cursors can be READ-WRITE, while client side cursors are
read-only. Why this is good? Because image such often task:
* you have query db.
* Get N records.
* show them in listbox
* Now user want EDIT SOME Nth record. Let even only ONE field.

Using mySQL or SqlLite you must produce UPDATE query, send it, then again
execute big original query to get back changes into new cursor.

Using server side cursors and API of Valentina you can do only

curs.Field( "f1" ).value = NewValue
curs.UpdateRecord

That is all, you have now updated db on server, and fresh values in cursor
which you still show in the GUI.


P.S. Yes, actually Bob describe above task of pre-load of some not visible
records. But to be able execute such task you must have SERVER SIDE cursors
instead of client-side.


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Losing data when quitting

[Till Bandi]

If you edit that field and quit Rev your changes will not be saved  
(there will be no Save dialog).



Can't reproduce this. I get the save dialog.

Till Bandi

Am 02.01.2009 um 22:51 schrieb Paul Looney:


Tim,
I doubt it is your imagination - and I thank you for raising this  
issue again.
If you create a new stack and put two fields on it, you'll observe  
the following:

When you open the stack the focus is on the first field you created.
If you edit that field and quit Rev your changes will not be saved  
(there will be no Save dialog).
If you leave that field with by tabbing, or clicking elsewhere on  
the stack, or clicking into the second field, or using the Enter key  
- then you WILL be asked to save the stack on quitting.
There may be other recipes as well, but the stack saving problem  
seems to be related to the lack of a closeField - which is not sent  
if the focus is still in the edited field when the stack is closed.

Is this what you are seeing?
Paul Looney

On Jan 2, 2009, at 1:28 PM, Timothy Miller wrote:


Damn!

I replicated it several times this morning, with care.

Now I can't replicate it. I haven't changed anything.

I'll wait and watch, to see if it occurs again.

Tim

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Large databases kaput?

[Nicolas Cueto]

Going out on a limb here...

If I understand you correctly -- namely,
you're trying to build a stack that has
5000+ cards -- then I think the problem
is not Rev's limitations but rather the
design you're envisioning for your stack.

Perhaps if you described a bit more what
you want your stack to do?

--
Nicolas Cueto
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution