problems with variables

[user#606]

Can anyone clarify the situation with the contents of variables.
In a table of data, text, numbers and flags I seem to have problems in using the extracted data.
Text is fine, but
put item 2 of DataTable into MyVar
may not result in a useable number.
answer MyVar + 6
produces an error as does doing put MyVar + 6 into AnotherVar

Is this because the TAB delimiter is also extracted? You can only see the number.
This would make the data a text form of a number, or not a real number.
If so, how do you convert the text form of a number to a real number.

[FourthWorld]

What delimiter character are you using between items, and what is the value of the itemDelimiter property at the time you're parsing your data?

[BvG]

You can only use the "+" operator with a number, anything else won't work. Try the add operator to add variables that are numbers, chunks of variables that are number, list's of numbers or arrays that only contain numbers. (note the focus on using numbers with this math operator)

[user#606]

To BVG
I only wish to apply a mathmatical calculation to the numbers, not concatenate.

To FourthWorld
The delimiter was tab and this was declared earlier in the handler.
Actually, there is no clarity in the Rev Dictionary about how frequently you use the delimiter statemant in a single handler script. It might be you only need to place it once, before any extraction operations occure or just before every extraction in the handler.

[BvG]

If you want to do math, make sure that you only do it with numbers, so vars that contain tab will not work. To concatenate stuff you have to use "&", "&&" or ",".

You can use "set the itemDelimiter to <char>" as often as you want. It will "stick" for the duration of the current running script. So if you issue another script, there the itemDel will be the default again (comma). Note that when you run a script from another script, then the original handler pauses. So keep in mind that the itemDel will be whatever it was set to in the current handler after the called second handler exits (example below). The Docu calls properties that behave this way "local properties".

Code: Select all

on mouseUp
  put the itemdelimter -- will be "," (comma)
  set the itemdelimiter to "a"
  myCustomHandler
  put the itemdelimiter after msg -- will be "a"
  -- the message box contains here ",,/a"
end mouseUp

on myCustomHandler
  put the itemdelimiter after msg -- will be "," (comma)
  set the itemdelimiter to slash
  put the itemdelimiter after msg-- will be "/" (slash)
end myCustomHandler

[user#606]

Hi BvG,

The whole point was the use of the data for math. I am aware of the concatenation bit. Thank you for your help in the delimiter respect.

But what do you do when the number you need to use has a tab stuck on the end of it. I would have thought someone else would have come across this problem. There must be a (well kept REV secret) way of extracting just the number part, as a "mathmatical" number.

I hope you can help?

[BvG]

There's various ways, depending on what is stuck at the end of your string, and what you know about the length of your string.

If you know that it's only one character at the end:

put char 1 to -2 of theVar into theVar
delete char -1 of theVar

If you know it's a whitespace (in rev these are equal to the wordDelimiter so quote ("), space, return or tab):

Code: Select all

put word 1 to -1 of theVar into theVar

If you know that it's only one word/item/line:

Code: Select all

put [word|item|line] 1 of thevar into theVar

If you know the number of chars that your number has:

Code: Select all

put char 1 to x of theVar into theVar

I'm sure there's quite a few more elaborate ways, for example using the format() function. I personally preffer to use "delete", especially when using repeat for each, like for example:

Code: Select all

on mouseUp
  repeat for each line theLine in field "List"
    if theLine is a number then
      put theLine + 1 & return after theNewList
    end if
  end repeat
  delete char -1 of theNewList -- removes superfluous return at the end
  put theNewList into field "List"
end mouseUp

edited for formatting

[user#606]

Thank you BvG, I can see this is a problem best avoided. There must be many applications in the technical arena that extract data from tables. For example excel files, for use within the program. It strikes me Rev have so many chunk thingies that they ought to have solved this one by now.

I do appreciate you efforts in helping me, and using your valuable time, it is very kind of you.

Alan

[BvG]

It strikes me Rev have so many chunk thingies that they ought to have solved this one by now.

How's it not solved? Delete is very good at removing superfluous chars, as are various other things. If you just want to add something to one number as you stated, that's a very simple way.

Just imagine you'd do this in C, where you can't get parts of strings without repeat loops, and you'd need to transpose the string into an integer or float, possibly loosing part of the number in process!

[user#606]

If it wasnt for the good will from people like yourself and the others that contribute, Rev would have failed by now. You guys are the keystone of their product.

I feel the pitfalls should be made clearer by Rev. The "so called" manual is a slightly wordier version of the dictionary. It is seldom useful in that respect. the dictionary has insufficient helpfull code segments to explain the options. The system has been around long enough to polish up these omissions. With the feedback from the Forum, you would have thought Rev would have used that as the focus for updating the manual.

Because my programming experience was in the dos era and the start of Windows, I cannot comment on other languages.
However, there was one software development system called Layout, which I found to be brilliant.
It makes all the present known languages look like a flint axe to a lathe.
There realy was no such thing as "code" to write, it was simply a matter of clicking on an element (like a block in a flow chart) and adding a few parameters. It was impossible to pick a wrong variable type or incorrect element and the software always worked. By that I mean, you got the program you wrote, not necessarily the one you wanted. No change there then!
The dos version had an apple style of windows and graphics and you could take your early dos (Layout) programs and convert them to Windows in a click of a button.
Why is it no longer around? the developer ran out of money.
It is always a great pity that good stuff can be killed off by rubbish, just because the rubbish is sold better.

[Janschenkel]

The documentation 'issues' should be put in perspective: the user guide that ships with Rev 2.9 is an excellent source of information, written from the 'topic' perspective rather than the 'API' perspective that the online documentation uses.

Finding information is always a 'chicken and egg' problem: you kind of need to know what you're looking for, in order to find the answers. A number of things that could improve the online docs:
- add synonyms from other languages
- allow users to contribute recipes in a system like MySQL has
- tie this online extension into the local help system

And while we're handing out suggestions, it would be great if they could:
- define guidelines and templates for tutorials
- host the good tutorials at the runrev site
- provide a community tutorials referral page like NetBeans has

Yes, the community is a cornerstone of Revolution's success. But in my opinion, the people at RunRev HQ are working very hard and improving the application and its documentation every time. Then again, the situation can't have been so bad if we all managed to figure it out

As there are more Java and .NET users, it is only natural that you will find more online examples, articles, books, etc. Unfortuantely, Revolution is not yet as popular as it ought to be, given how easy it makes cross-platform development it should be considered one of the best-kept secrets of modern software creation!

But like any other languages, there will be differences, not merely in syntax but also in the frameworks, which means there is an initial hurdle that some people have an easier time with than others.

Multiple lengthy examples per keyword would be great, but given the array of commands and functions, that would be a mammoth task. So if the team could find a way to empower the community to help them in that regard, you could immerse yourself faster.

My two cents,

Jan Schenkel.

[user#606]

Hi Janschenkel,
What you say sounds sensible, however, the people writing the Manual understand their product and fail to see it from a new person perspective.

I respectfully take issue with you about "Then again, the situation can't have been so bad if we all managed to figure it out". The issue is that in all probability you and some others are highly intelligent and those who are less so are avid users of Rev to overcome the learning curve. Fine then if you are clever and/or a keen hobbyist, you have the time.
Some people use the product to solve a particular problem, like I am doing. I know how to program, and have an urgent commercial project to fulfil. I was duped by the sales pitch.

Rev have an excelent product, but have failed to appreciate how vital it is to their business to have one that is easily learned.

I believe less is more. If better attention was paid to the basics, the user would be better placed to know the questions to ask. The dictionary would then become better used and understood. Bearing in mind this is a language, it would be helpfull if the clear gramatical rules were stated. And adhered too.

To conclude, I agree with much that you say, perhaps if the Rev people appreciated that souls with normal intelligence would like to use their product, they would sell more and be a name as familliar as C.

[FourthWorld]

If I understand user606 correctly, all that's needed is the briefest introduction to the itemdelimiter, and a gentle reminder that whenever things may seem more complicated than that in Rev it's more often than not merely a perceptual issue.

One can store lists if things in variables or other containers delimited with anything you like. Generically these are called "items", and there is an "itemdelimiter" property so you can tell Rev what you're using. By default items are delimited by commas, but you can set the itemdelimiter to tab or any other character.

There are also other "chunk" types: lines (by default delimited by return characters) and words (by default delimited by space characters).

For simple tab-delimited text, this will suffice:

set the itemdel to tab
add item 3 of line 7 of tMyData to item 5 of line 7 of tMyData

There are likely more optimized ways of doing that depending on the specifics of how you're doing the addition (to just one line or many, adding just two elements from the same line or many, etc.), but that brief example should hopefully inspire a simpler understanding of how to work with itemized lists.

As far as the manual goes, learning any new language will be challenging at first, but I've found those who make the most money with this one started by reading the Intro in the manual and then for things related to text moving on to Chapter Six: Processing Text and Data. True, that's a lot of material and may seem daunting at first, but if what you came across looked merely like the Dictionary I dare suggest you might not have been looking in the right place.

In my 20 years in this business I've never seen any proprietary language for which users didn't complain about the docs, and I do believe there's always room for improvement.

That said, I also find that a good many people have gone from zero to pro with worse docs than are in the current version, so there must be some merit to doing with Rev what must be done to learn any language:

You read a lot, you make simple projects to explore what you've read, a lot of stuff you write doesn't work as you first expected, you revise and try again.

From Assembler to C to BASIC to Pascal, I've never seen any programming language that was learned any other way....

[user#606]

Thank you for your help and advise, I appreciate it.