Recently, I had a problem with a client using McAffee. She updated her virus definitions and programs. It caused the performance of OI to TANK until she excluded the ".ov" extention. The ".lk" was already excluded. I could duplicate the performance issue using Norton too.

No real question here, just an FYI in case anybody else runs into this.

This has been documented for a long time .. since early REV days. The old DOS program type .OVL were the culprit .. REV uses .OV, but scanners use .OV* for their mask.

Don

The last time I used AREV was back when the only people who had an "INTERNET" account were the geeks at universities. So the virus problem was not that huge yet either. It was still a time when you got a virus was by booting on someone else's floppy (you recall the 5.25" ones).

Needless to say, things have changed since then. When I got OI last year to write a system for a friend I read the white papers on AREV to OI and scanned the boards (thank heaven for the CELL HELL postings). I downloaded any code/application samples I could find to review them for style and technique.

However, little issues like the virus software still plague me as an OI newbie. Frequently, my searches on the boards result in no answers (I guess my keywords are off key). I post and then someone points out where I should have looked. If there is a white paper on the stupid mistakes I should avoid I'd love to read it.

Until I get the magic decoder ring that was missing from my OI Software package I suspect I will post more things that are obvious to the more experienced. Hopefully, my ignorance and the resulting postings might help some other newbie down the road.

Hey Dave, I do similar postings. And anyways… many times I learn things when I read posts here, that most have already knew.

It just about kills me when I have programmed like 30 lines of code to handle something, share it here, only to have another comment that there is this "undocumented" item that does it too.

Sometimes it seems that everyone except for me knows about this "undocumented" item.

Oh and your post has reminded me to remind my customers to be sure not to do what you mentioned. Thanks.

Dave,

Don't forget, when you ask a question, others get to see the question and the answer. That's really helpful to other newbies. For example, after this post, I immediately checked the Cell Hell thread, which I found extremely useful. Thanks for the pointer!

Speaking of that thread, I have three questions:

1. Has anyone modified the code to work in a single-column edit table?

2. Ray said the modified version allows him to select colors and use Edit Cell. I can't seem to get them both to work at the same time. Is there something I am missing? I am pretty much using the posted code as is.

Thanks

David Kafka

David,

Not sure what you want to do, but I heard my name ("Ray" I think?). Any case as you will see in the below link (make sure you include everything) Oystein was a big help with the Edit Cell issue for me. My advise is don't use my code, use what Oystein provided . He did this in Norweigian first then translated it into English. It's really remarkable that it worked. It's a testament to the excellent school system in Norway especially as you get to know Oystein.

http://www.revelation.com/__8525656100571cbb.nsf/0/DB8B83BC1D251CA8852568E7002FB3F8?OpenDocument

Let me know how I (with some minor input from Oystein) can help) ).

Ciao,

Ray

P.S. Oystein will have to explain the code as I can only cut and paste. That is a testament to the American school system.

P.S.S. If I knew how to embedded the link into some attractive tag like "see here", I would have done that, but am too lazy to research it up for now.

Ray,

I used your name because I was hoping you were listening. I am using Oystein's code, and what I want to do is exaclty what you wanted to do when you started the Cell Hell thread a couple of years ago. I have even set it up as my first set of promoted events! However, I am having the problem which you originally said you had: If I use the code as written, the selected cells do not properly change color. It's not really a big deal to me, I am just trying to figure out why.

A new question, though. I was trying to figure this out on my own, but I can't quite do it. The EditTable leaves behind a trail of highlighted rows as it loses focus. I have modified Oystein's code just a little so that when the EditTable loses focus, I set the SELPOS property to the first row, so that the highlight is at least there. The highlight seems to be associated with the SELPOS property. But I want it to go away altogether when the EditTable loses focus. Any thoughts?

(For now, I am working with single-column edit tables, just because that happens to be what is in this form I am experimenting with. I have also modified Oystein's code to work with single column EditTables; I suppose that could explain why I am having problems.)

David

David,

To get rid of the blue SELPOS highlighting in edit tables altogether: Untick Permit row selection in Edit Table Properties - More.

- Oystein -

David,

I've kept the window and the edit table where I did that programming I posted in The Cell Hell thread. I got out that window now and reduced the edit table from three columns to one. Everything did still work.

I don't believe I did any changes to the programming since it was posted. I know I changed a couple of comments, but can't remember any changes of significance. But in case I'm wrong I'll publish the code once more here.

I suggest you revert to that programming and take it in small steps from there.

Or post your code here so I and others can have a look at it.

- Oystein -

Currently at

---

GOTFOCUS:

declare function Send_Event

declare subroutine Forward_Event

declare function Get_Property

Forward_Event( PrevFocusID )

/* always enter edit table in top left cell.

 also see comment for TOPPOS in POSCHANGED handler */

UnUsed=Set_Property( CtrlEntID, "SELPOS", 1 : @FM : 1 )

/* in one of my responses to Ray I said I might have forgot to initialize @PREVPOS here,

 but I don't really think it's necessary.

 because the first time the edit table gets focus

 @PREVPOS is not used yet and therefore is empty.

 and later times the previous LOSTFOCUS/POSCHANGED

 did the job of blanking it out.

 but of course it cannot hurt, so here goes: */

UnUsed=Set_Property( CtrlEntID, "@PREVPOS", "" )

Pos=Get_Property( CtrlEntID, "SELPOS" )

UnUsed=Send_Event( CtrlEntID, "POSCHANGED", Pos, Pos )

RETURN 0

LOSTFOCUS:

declare function Send_Event

/* fake a POSCHANGED */

/* next column/row are zero to signify lost-focus */

UnUsed=Send_Event( CtrlEntID, "POSCHANGED", 0, 0 )

RETURN 0

POSCHANGED:

$insert Colors /* or Color_Equates */

$insert Logical

declare function Send_Message

declare function Set_Property

declare function EditCell

/* check the current and previous position.

 only act if the current position is different from the previous one */

CurrPos =NextColumn : @FM : NextRow

PrevPos=Get_Property( CtrlEntID, "@PREVPOS" )

if CurrPos # PrevPos then

/* reset colour of previous cell */

OrigBackColor=WHITE$

OrigForeColor=BLACK$

UnUsed=Send_Message( CtrlEntId, "COLOR_BY_POS", PrevPos, PrevPos, OrigBackColor : @FM : OrigForeColor )

/* we want to programmatically leave the edit table

 if the user is finished entering data.

 we assume she's finished if she tabs out of an empty first column cell.

 we cannot distinguish between tabbing or clicking, but we can check for the rest, i.e:

1. the previous cell is in column 1, and

1. the previous cell is empty, and

1. the current cell is in column 2 on the same row.

 perhaps also

1. the current cell should be empty.

 NOTE! this code assumes there are at least 2 columns in the edit table */

if (PrevPos=1) and (CurrPos=2) and (PrevPos=CurrPos) then

PrevValue=Send_Message( CtrlEntId, "TEXT_BY_POS", PrevPos, PrevPos )

CurrValue=Send_Message( CtrlEntId, "TEXT_BY_POS", CurrPos, CurrPos )

if (Trim(PrevValue)=") and (Trim(CurrValue)=") then

ProgLeave=true$

end else

ProgLeave=false$

end

end else

ProgLeave=false$

end

if ProgLeave then

/* programmatically leave edit table */

NextCtrl=Get_Property( CtrlEntId, "NEXT" )

UnUsed=Set_Property( "SYSTEM", "FOCUS", NextCtrl )

end else

/* set colour of current cell - if there is one

 (there's not one when you leave the edit table) */

if CurrPos and CurrPos then

BackColor=RED$

ForeColor=YELLOW$

UnUsed=Send_Message( CtrlEntId, "COLOR_BY_POS", CurrPos, CurrPos, BackColor : @FM : ForeColor )

end

/* remember position to next time */

UnUsed=Set_Property( CtrlEntID, "@PREVPOS", CurrPos )

/* set edit mode - unless we've left the edit table */

if CurrPos and CurrPos then

UnUsed=EditCell( CtrlEntID, true$ )

/* it seems EditCell sets the SELECTION to the whole content of the cell.

 to a user that can seem like overwrite mode.

 deselect and set caret before first character in cell */

UnUsed=Set_Property( CtrlEntID, "SELECTION", 1 : @FM : 0 )

/* or, depending on taste, use this version to set caret after last character: */

/* or UnUsed=Set_Property( CtrlEntID, "SELECTION", 9999 : @FM : 0 ) */

end

end

if ProgLeave or not(CurrPos and CurrPos) then

/* we've left the edit table,

 either programmatically or the normal way.

 reset scroll to top left cell.

 we would also like to reset selected position (SELPOS) to same,

 but if we do it here we get another POSCHANGED.

 so it's better to set SELPOS in the GOTFOCUS handler */

UnUsed=Set_Property( CtrlEntID, "TOPPOS", 1 : @FM : 1 )

end

end

RETURN 0

David,

As I said, use Oystein's code. I do and it works. There may be some minor tweaking to meet all situations, but otherwise, it's pretty solid.

Oystein,

Jeez, how do you store all this in your head?

Skål!

Ray

Ray,

In my head? Are you crazy? In my head are just suspicions, hunches, vague remembrances and distorted echoes. When I want to know something I search my files and the lists.

- Oystein -

View this thread on the Works forum...