sequence of lines

[ASJ Botenga]

Thank you for the attention you already gave to my questions and comments,
also again here below, and for the prompt answering. It is a pity that, as
far as I know, there are no people in the Netherlands who deepened
themselves in Panorama.

Allard

op 01-06-2008 20:48 schreef David Thompson op dthmpsn1 at illinois.edu:

>> Back after a few day¹s I see the solution you offered. I am impressed by the
>> way you managed to avoid to affect the general memory.
>> However, when the memory is in use at the point of introducing in a macro,
>> Œnoyes¹ Œgetscrap¹ or other windows that affect he memory, you could handle
>> as follows for the same task (m=clipboard(), a=text):
>> 
>> a=m+"€"+a noyes "do you want a sequence of lines now"
>> if m="Yes"getscrapok "typ 1rst line dot last line"a=a["€",-1][2,-1]
>> selectwithin seq()=>val(m[1,"."])and seq()¾val(m[".",²€²][2,-1])stop
>> else m=a[1,²€²][1,-2]a=a["€",-1][2,-1]endif
>> If you don¹t want to see the little hesitation as compared to your solution
>> with less intern calculations, start with HIDE.
>> In stead of € you can use other unique symbols, like "`","^","å","®"
> 
> This is essentially a restatement of the way that
> arrays work. The € is your separator character.
Although I (ab)used the clipb., I am a little content I invented that
myself.

> It would probably be helpful to know which
> version of Panorama you are using, how long you
> have been using it, and which versions you have
> used in the past. The Panorama II Handbook uses
> the word "Macro" as you do, but all the
> documentation written in the past 12 years,
> covering versions 3.0 and later, has used the
> word "Procedure." This leads me to believe that
> you may be relying on documentation that is more
> than a decade out of date. I don't know if your
> software is similarly out of date.
I use the term Macro in general, as I think programmers still do. For
Panorama in particular I use 'Procedure', as might have been noticed. If
Macro disturbs people I won't use it anymore. I am working in Panorama
3.1.5, the last version with active 'Equations' in the Design Sheet, witch
is highly essential for, and extensively used by me, but have access to the
latest version. After "Overvue" I started with Panorama and I think I might
say that in the meantime, by try and error and reading, I can solve any
problem and provide an answer, i.e. Procedure, to any question. However, I
am sure that I probably use less than 10%, perhaps not even 5%, of the
possibilities of Panorama and that my efficiency can be (greatly) improved,
as was shown recently by the little program (with extra field and loop) to
separate zero's from empty cells in stead of using SIZEOF. Some Procedures
however with loops within loops within or surrounded by equations and
complex true-false comparisons may perhaps show some efficiency.
>> 
>> You can solve many but not all choices offered during a running procedure
>> using variables, but I am afraid the (general) memory cannot always be
>> spared. Panorama, though it is an excellent programm, alas, has only one
>> memory (my calculator has allready 6). Therefore I found it usefull to
>> expand the memory by using a little trick with symbols.
> 
> You seem to be using the term "general memory" to
> refer to the clipboard. It is true that there is
> only one of these, but it belongs to the computer
> system as a whole, and not to any one
> application. The various applications that are
> running on your machine must share it.
>
> Variables exist to give your procedures as many
> "memories" as they require. A procedure that
> needs 100 memories can declare 100 variables.
Is it not so that the unique value of the clipb. for procedures remains the
possibility to copy, like a chameleon, date, text or numeric data from a
database and paste these on other lines in any given field.

As far as variables are concerned I was already convinced that careful
reevaluation of my larger procedures will give me still a lot of work to do.

> The "noyes" and "getscrap" statements are both
> out of date since Panorama 3.0. They still exist
> in later versions of Panorama, because procedures
> that were written with earlier versions need to
> continue to work, but their use is discouraged,
> because they affect the clipboard. There are
> alternatives that don't affect it. My previous
> email on this thread used Alert 1014 (or
> AlertNoYes) in place of NoYes, and it used
> GetText in place of GetScrap

>> There remains a question, however. Since I write a bit complicated financial
>> programms using panorama, during the running of these one is frequently
>> asked to make a choice, I am always looking for a shorter macro-text. It
>> should be very usefull if the word clipboard() could be changed in only the
>> lettre m, which is equally understandable. Might there be a possibility -
>> with a feature I could not detect and possibly missed - to have this
>> changement realised?
>> Other abbreviations might be ³down, up, first or last² i.s.o. adding
>> Œrecord¹
> 
> Beginning with Panorama V, you can write custom
> statements and functions. You could create a
> custom m() function that would be the same as
> clipboard(). The () are necessary for Panorama to
> recognize it as a function, and not a field or
> variable. You could write a custom statement
> called DOWN that would do a DownRecord, and one
> called UP that would do an UpRecord, and so on.
Excellent. Probably I will be back with some questions in this respect.
(The necessity of () I learned from earlier experiences)

> The ALERTNOYES statement I mentioned a little
> earlier is a custom statement that comes with
> Panorama. Writing something like
> 
> AlertNoYes "Do you want to continue?"
> 
> would be the same as writing
> 
> Alert 1014, "Do you want to continue?"
> 
> In either case, you would use
> info("DialogTrigger") to find out which choice
> was made, instead of clipboard(), because the
> clipboard would remain unchanged. If you wanted
> to make a dlgtgr() custom function to use in
> place of
> info("DialogTrigger"), you could do that too.
> When a custom statement is named, its name is in
> UPPER CASE LETTERS, but when it is used in a
> procedure, you can use aNy COMbinATION oF UpPer
> and lowER CASE that you like.
> 
> Dave

> "you can use aNy COMbinATION oF UpPer
> and lowER CASE that you like"
Sure, as well as you can leave out most of the spaces.

> _______________________________________________
> Qna mailing list
> Qna at provue.com
> http://provue.com/mailman/listinfo/qna