Query the contents of a bracketed Screen Attribute [MYATTR]

General development discussion.

Moderators: Susan Smith, admin, Gabriel

Post Reply
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Query the contents of a bracketed Screen Attribute [MYATTR]

Post by Susan Smith »

Is there a way to query the contents of a bracketed screen attribute OTHER THAN redirecting STATUS ATTRIBUTES to a file and then reading the file back in until you find that attribute? I'm looking for some way that is similar to how we query environment variables (or something equally quick).

There are some attributes that I want to TEMPORARILY change for a particular program. So I plan to query the CURRENT contents of the attribute and save that aside, and then put it back when I'm finished with CONFIG. This involves someone else's code, and I don't have the option to use a different attribute code.

-- Susan
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

Post by John »

if your brconfig.sys sets the attributes
then your code or someone else's code changes it and you want to set it back... try just


execute "Config Include BRConfig.sys"
John Bowman
bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Re: Query the contents of a bracketed Screen Attribute [MYAT

Post by bluesfannoz »

Susan
I don't have an answer other than what you said of piping it to a file and reading it in. But I will chime in here once again and make the request that we be able in the future to pipe this output to a Variable rather than a file. Then I could quickly search the variable using POS to find what I need. Rather than writing to disk. Reading it in.. Which on some systems can be super duper slow...

I have made this request at several conferences and seemed to get support from everyone that this would be a good idea... but as of yet have not seen it implemented as a feature. If its not in 4.18 or 4.2, I think it will be too late to be useful. Because I will have already had to dedicate too much time into the code I made work without it. By the end of the year I will have all my clients on 4.18i. Upgrading releases is a major undertaking. I will not want to have to do it again for awhile.


Steve

Susan Smith wrote:Is there a way to query the contents of a bracketed screen attribute OTHER THAN redirecting STATUS ATTRIBUTES to a file and then reading the file back in until you find that attribute? I'm looking for some way that is similar to how we query environment variables (or something equally quick).

There are some attributes that I want to TEMPORARILY change for a particular program. So I plan to query the CURRENT contents of the attribute and save that aside, and then put it back when I'm finished with CONFIG. This involves someone else's code, and I don't have the option to use a different attribute code.

-- Susan
Steve Koger
Computer Specialist
SEKESC-MACS Division
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

I'm with you Steve. I would LOVE to be able to get at these attributes with a variable that I can search.

If that can't happen, how about a pseudo-function call/environment statement where I could write
let a$=env$("[MYATTR])" where the CONTENTS of that attribute gets dumped into the a$ in this case. It would act like a function call (in the perfect world in which I live <g>)

John - I don't have the option to include BRCONFIG.SYS in this case - this has to happen within one program once BR is launched. But thanks for the idea anyway. I'm dealing with a compiled program (for which I don't have source code) that sets attributes with CONFIG statements.

-- Susan
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

Have you tried STATUS ATTRIB ? THis will list all of yourbracketed attributes and their contents. You could query this and then parse the text file.

FNGEORGE
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

That's what I'm doing now. But on some workstations on the network, it's noticeably slow. So I was hoping for a better alternative. What I may have to do in the meantime to cut down on that time is dimension a large variable and read the entire file into it at once, so I can find what I'm looking for with POS statements rather than LINPUTing each line and examining it separately. At least that way, it's only one disk read.

For anyone wanting to try that...
01970 DIM STAT$*30000
01990 EXECUTE "status attrib >ATTRLIST.TXT"
02010 OPEN #1: "name=ATTRLIST.TXT,eol=none",DISPLAY,INPUT
02020 LET X=LREC(1): LINPUT #1: STAT$: CLOSE #1:

Then find what you want with a POS statement.

-- Susan
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

Since you can set an attribute based on another attribute you can transfer your attribute to a temporary attribute, reset your main one and then when done set it back to the origina

config attribute [TEMPD],[D]
config attribute [D],N/W:T

do some stuff

config attribute [D],[TEMPD]

fngeorge
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Now THAT's interesting! Thank you.

-- Susan
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

Woah! Really?!?

Thats pretty cool...
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

George pointed out a nice way to create temporary attributes, but when using a text file to parse information, you can do something like this:

exe "stat attrib >"&env$("TEMP")&"\Attr-[Session].txt"

OPEN #1: "name="&ENV$("TEMP")&"\Attr-[Session].txt",DISPLAY,INPUT

This is a lot faster than using the network. By using the [Session], you also avoid any sharing issues, so windows can safely use the CACHE to improve performance.
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Do I understand this correctly that you're basically storing an entire text file into an environment variable? Are environment variables subject to the same size limitations as other variables?

-- Susan, getting some ideas about storing other "global" information all in one ENV$ variable
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

No, the file is being created in the users "TEMP" folder. Essentially the same as you already do, but on a faster driver.
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Oh, I see that now. Thanks. Faster is better, no matter how you get there!

-- Susan
Post Reply