I have a window which was working okay. Now when I enter a new item, I get a SaveWarn message after the key field in entered. I'm not trying to close or clear the record.

If I enter a key for an existing item, no savewarn message appears(as you would expect). Why am I getting a savewarn after the key field for a new item is entered?

I've looked and looked and don't see what I could have possibily changed or done to cause such a behavior. I've traced this to occuring after the READ event is fired. I have looked on this forum and have tried various voodoo tricks, such as, in the Read Event, I've placed the following "spell". Don't think I should need this, but tried it and it didn't help unfortunately.

Focus=Get_Property(@Window, "FOCUS")

call Send_Event(Focus, "GOTFOCUS") (and even 'LOSTFOCUS')

Set_Property(@window,"SAVEWARN",False$)

Does anyone have any idea where I should look to get rid of this savewarn message when entering a new transaction.

Thanks much. I shall also post this on the otherside (not the Dark Side)

[email protected] onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Sorry for the unwarranted plea for help. Two minutes after I sent the message, I looked at the Create event. Sure enough, if the item was new, I was doing the following:

• fill in EntryDate

Set_Property(@window:".ENTRY_DT","INVALUE",Today.Dt )

Well I guess that this somehow confused the Read Event and cause the SAVEWARN message. To remedy this, I then stuck this in:

Set_Property(@window,"SAVEWARN",False$)

That fixed it. Again, thanks.

[email protected] onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Ray ..

Unless the form is a one-shot (only 1 record then close) then you'd be better off to hook your code to the read event. If it is a new record then set the DEFPROP property of the date field to today's date or whatever. This will trigger the SAVEWARN later on. If you do it on the create event you are likely to trigger the read event with a null key.

Don Miller

C3 Inc.

Don,

Thanks for the suggestion. I have already (slowly but surely) figured it out that the Read Event is a better place.

Things are coming together. However, what's your fix on the Jrev situation? If you rather not comment here, you can e-mail me separately.

Thanks,

[email protected] onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

I'm not a bit shy. This will probably stick around long enough for you to read it.

JRev will probably be late and will not be as robust as was hoped for given the fact that RTI's lost a lot of talent and what's left is scrambling just to keep up. It's a shame but that's the way life is. As to the future .. who knows. We've opted to continue our efforts on the assumption that if things work out, then we're ahead of the game there. If they don't .. then we've learned a lot along the way and will be able to take advantage of whatever's out there.

If I were you, I wouldn't bet on a 32-bit version OI any time soon, if ever. There's a funny thing about 32-bit stuff anyway .. Some of my benchmarks indicate that string-based manipulation can be slower in 32-bit mode than in 16-bit mode. Since Linear Hash is one big string manipulation engine, there may not be a big benefit except for getting around addressing issues, etc. Nonetheless, it is perceived that if it ain't 32-bit, it's dead.

What is more upsetting to me is that the MV / Variable Length world is rapidly shrinking and that's too bad. There are many applications that are easy in this world that are nothing short of awful in other environments. What I see now is either very high-end data managers that carry a high price tag and require mucho resources to get off the ground (ORACLE, for one), or toys (Microsoft Access for example).

Enough of my soap box ..

Don Miller

C3 Inc.

Don,

In general I concur with your view - a loss of key guys must have some hit and will be sorely missed- but as I understand it the stage that JRev has reached, some of the key work is tying in LH and data typing etc. Guess what - Pat is the EXPERT in this field and is well upto speed in Java. So the project should progress with enough support from all directions.

BTW there are two third party OI projects floating round. One of those I suspect will gradually go the way of so many ideas born of enthusiasm and invention but no commercial sense. The other .. well coud be interesting. However the JRev project still remains the most exciting, scalable and flexable - allowing developers to use what they want and plug in their own variantes.

View this thread on the Works forum...