{{tag>category:"OpenInsight Specific"}} [[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]] ==== Still trying to by-pass "SAVEWARN" (OpenInsight Specific) ==== === At 15 DEC 1998 04:48:30PM B. Cameron wrote: === Well I have been away from it for a bit but I am still having trouble with forms allowing updates when I would like to disable them. I have about 11 windows that in the create event I call a stored procedure and check for a screen login name. If the user is a "view" only, I then, in the stored procedure, set the menu.file.delete and menu.file.save vars to disabled. This is fine except that if the user changes anything then the "SaveWarn" event is submitted. I would like to by-pass or set this so no info on any form can be changed for this session. I tried the suggestions that Cameron had given me in an earlier thread but had no luck in implementing them correctly. Can anyone give me any more detailed information? It would be greatly appreciated. Thanks. ---- === At 15 DEC 1998 07:08PM dsig@teleport.com wrote: === When we call a window to generate a 'known' new record and SEED that window with info .. after the forced read and stuffing we .. Rtn=Set_Property(@Window,"SAVEWARN","") Then if the user closes at that point they don't get that message .. hope this helps dsig@teleport.com David Tod Sigafoos ~ SigSolutions voice: 503-639-8080 ---- === At 16 DEC 1998 05:35AM Oystein Reigem wrote: === BC, What Cameron and David seem to say, is use $insert Logical Rtn=Set_Property( @Window, "SAVEWARN", false$ ) in the CLOSE handler, but with a Focus=Get_Property( @Window, "FOCUS" ) call Send_Event( Focus, "LOSTFOCUS" ) first. I cannot get it to work either. But I thought I had a different suggestion for a solution. You see I asked Carl Pates earlier this year what to do if I wanted system warnings in my own language. He said something about intercepting system messages. And I assume once you have intercepted, it will be equally easy *not* to issue any warning as to issue a warning in Norwegian. I haven't implemented it yet, but according to my notes a user SYSMSG event like ...issue Norwegian system message no MsgCode... return 0 would solve *my* problem, and $insert PS_EQUATES if MsgCode=SYSMSG_SAVEWARN$ then return 0 end else return 1 end would solve yours. Except that it doesn't quite work! I made a test window with "your" version of the handler. I filled in some data and tried to close without saving. The SAVEWARN message was skipped all right, but the window wouldn't close. I will have the same problem with my version of the handler. Anyone in the know listening? - Oystein - ---- === At 16 DEC 1998 10:27AM B. Cameron wrote: === Oystein, Thanks for the response. I too, had the same results. The window would not close. Also, when I removed (destroyed) the code in the event it still acted as though it was there and I had to revert to a saved copy of the window. I also tried set_prop(@win,"SAVEWARN","") in the read event but had no luck. Ideally I would like to set the by-pass in the SSP as this is already set up for all launched forms and I would only have to put the code in once but I am unsure of how to this also. Bruce ---- === At 16 DEC 1998 11:10AM Cameron Revelation wrote: === Bruce, If you set SAVEWARN to 0 after sending a LOSTFOCUS to the current control, it should close without a message. Cameron Purdy Revelation Software ---- === At 16 DEC 1998 11:18AM B. Cameron wrote: === Cameron, Thanks, is does do that, but then the window will not close. I did this... Focus=Get_Property( @Window, "FOCUS" ) call Send_Event( Focus, "LOSTFOCUS" ) x=Set_Property(@WINDOW,"SAVEWARN",0) in the Close event of the window. Bruce ---- === At 16 DEC 1998 12:52PM Don Bakke wrote: === Bruce, Make sure you are returning a 1 in your CLOSE event (I forgot to mention this in my e-mail as well). dbakke@srpcs.com [url=http://www.srpcs.com]SRP Computer Solutions[/url] [img]http://www.srpcs.com/srpicon1.gif[/img] ---- === At 16 DEC 1998 02:48PM dsig@teleport.com wrote: === Oystein, Sorry to conflict but I did not say to use false. Try using "" instead. For some reason this seems to work. If it doesn't let me know dsig@teleport.com David Tod Sigafoos ~ SigSolutions voice: 503-639-8080 ---- === At 16 DEC 1998 02:54PM dsig@teleport.com wrote: === been bit by that self-inflicted bug before dsig@teleport.com David Tod Sigafoos ~ SigSolutions voice: 503-639-8080 ---- === At 16 DEC 1998 11:51PM Don Bakke wrote: === Cameron, I've followed up on this issue with 3.7 and I am getting the same results as Bruce. Can you please confirm this on your end? In the meantime, the workaround is to set the focus to another control first, probably the key ID, and then set SAVEWARN to 0. This seems to work fine. dbakke@srpcs.com [url=http://www.srpcs.com]SRP Computer Solutions[/url] [img]http://www.srpcs.com/srpicon1.gif[/img] ---- === At 17 DEC 1998 06:44AM Oystein Reigem wrote: === David, [i]Sorry to conflict but I did not say to use false.[/i] Just tried to make the code clearer. [i]Try using "" instead. For some reason this seems to work. If it doesn't let me know[/i] Here it seems to make no difference. It still doesn't work. (I haven't yet read the rest of the thread, though.) - Oystein - ---- === At 17 DEC 1998 07:02AM Oystein Reigem wrote: === David, [i]been bit by that self-inflicted bug before[/i] Aaaaargh!!! - Oystein - ---- === At 17 DEC 1998 11:32AM dsig@teleport.com wrote: === Oystein, Not sure why I use "" but that I got if from someone elses code that worked . You know it was just one of those 'arms flapping in the air .. running around in panic screaming DANGER WILL ROBINSON'. I just say Don's recent post and then went over the processing .. On the GOTFOCUS event for the key control I check to see if we are to create a new record automatically and if so then i do some processing to generate the new id, send_event lostfocus (to force the read) and then in the read I stuff the controls with passed information THEN clear the SAVEWARN. As he mentioned .. have you done the lost focus on the control? dsig@teleport.com David Tod Sigafoos ~ SigSolutions voice: 503-639-8080 ---- === At 17 DEC 1998 04:48PM B. Cameron wrote: === Thanks to Don Bakke for the information to solve this problem. Thanks to all for the responses. I did try all of the above and as noted was not getting the right solution but Don suggested.... rv=Set_Property(@Window:".EDITLINE_1", "FOCUS", 1) rv=Set_Property(@Window, "SAVEWARN", 0) Return 1 be put in the CLOSE and/or CLEAR event(s) of a form and it DOES by-pass the warning and will not update. Happy holidays! B. Cameron Alternative Systems Softworks Inc. 603-433-0014 ---- === At 18 DEC 1998 04:43AM Oystein Reigem wrote: === David, If you read my other reply ("Aaargh!!") you know where I missed. I suddenly got this vision with Death coming to my door asking: Oystein - do you want a "return 0" or a "return 1"? - Oystein - ---- === At 18 DEC 1998 10:38AM Cameron Revelation wrote: === Hi Don, Could you explain ... I looked over the thread and do not understand the problem? Could this be something to do with the edit box (cr/lf vs. tm or something like that) issue that you reported? Cameron Purdy Revelation Software ---- === At 18 DEC 1998 11:42AM Don Bakke wrote: === Hi Cameron, No, this is not the multi-line editbox problem. Here's a simple way to duplicate the problem: 1. Create a Window with just a key ID control and one regular databound control (make it an editline for simplicity.) 2. In your procedural CLOSE event (not QuickEvent) enter the following code: Declare function Send_Event Focus=Get_Property(@Window, "FOCUS") rv=Send_Event(Focus, "LOSTFOCUS") rv=Set_Property(@Window, "SAVEWARN", 0) RETURN 1 3. Save, compile, and test run. 4. Bring up a record, change the data, then close the window. You will get the SAVEWARN message, despite the fact that a LOSTFOCUS has already been sent to the current control. I have checked the value of the SAVEWARN property after the LOSTFOCUS and it does get set to 1, so this is working. However, it appears that GOTFOCUS_VALUE must not be getting reset (which may or may not be a good thing) because when the system sends its LOSTFOCUS event then SAVEWARN is getting set again. Therefore, the workaround is to set FOCUS to another (non-editbox) control because it is guaranteed that its GOTFOCUS_VALUE and DEFPROP properties are the same (well...I guess there could be some exceptions such as an empty control with a default. This is why I suggest the key ID control since it must already be filled in.) I don't want to classify this as a bug, necessarily, because I do understand the logic of the system. But I would like it confirmed on your end that what we are experiencing IS the expected behavour. Thanks, dbakke@srpcs.com [url=http://www.srpcs.com]SRP Computer Solutions[/url] [img]http://www.srpcs.com/srpicon1.gif[/img] ---- === At 18 DEC 1998 02:22PM Gene Gleyzer Revelation wrote: === Don, The logic of system CLOSE event is quite simple: If the SAVEWARN flag is not set Check whether the content of the control whith focus changed compare to the value that was saved out at GOTFOCUS event If different, set the SAVEWARN flag End If the SAVEWARN flag is set Send the SYSMSG, SYSMsg_SAVEWARN$ event return End Proceed with the CLOSE event Having this in mind, your code is almost correct -- the only things to change is to replace the rv=Send_Event(Focus, "LOSTFOCUS") with rv=Send_Event(Focus, "GOTFOCUS") to force the new value be used in the comparison. Gene ---- === At 18 DEC 1998 07:51PM Don Bakke wrote: === Thanks Gene, it works for me. Now we have two ways of getting this done: One that avoids the need to hardcode or calculate the key ID prompt, and another that avoids the multiline editbox problem. Guess it depends on which contingency we would rather deal with . dbakke@srpcs.com [url=http://www.srpcs.com]SRP Computer Solutions[/url] [img]http://www.srpcs.com/srpicon1.gif[/img] ---- === At 19 DEC 1998 12:48PM B. Cameron wrote: === Don + Gene, Not to beat a dead horse butt... If I have a Main MDI frame that launches all my data entry/view forms and in each I call a SSP from the Create Event of each form... could I accomplish this with promoted events and thereby centralize my code ?? Bruce ---- === At 19 DEC 1998 10:21PM Don Bakke wrote: === Bruce, Absolutely! We have an application right now that is about 80% promoted event driven versus 20% control level event driven and this is built around our Win98 MDI Frame utility. We deploy this app to those who want our Win98 utility so they can see it fully fleshed out and in use. If you want to begin understanding promoted events I always recommend beginning with the [url=http://www.sprezzatura.com/senlv1i7.zip]Sprezzatura Electronic Newsletter Volume 1 Issue 7[/url]. This has a good article by Andrew that gets you on the right track. Enjoy! dbakke@srpcs.com [url=http://www.srpcs.com]SRP Computer Solutions[/url] [img]http://www.srpcs.com/srpicon1.gif[/img] ---- === At 20 DEC 1998 07:49AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura, Inc.[/url] wrote: === There was an article in [url=http://www.sprezzatura.com/v2i2.html]SENL Volume 2, Issue 2[/url] that might help some with this. akaplan@sprezzatura.com [url=http://www.sprezzatura.com]Sprezzatura, Inc.[/url] [img]http://www.sprezzatura.com/zz.jpg[/img] ---- === At 20 DEC 1998 07:55AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura, Inc.[/url] wrote: === Gene, I had a similar problem with the some time ago and found that when the current control was an edit box, and there was more than one line on the edit box, you always got the savewarn message since one portion was comparing inval and the other default, or something like that. Anyway, the end result was that you were comparing a CRLF delimited string with a @TM delimited string, they were not equal and it bombed. I have full documentation on this at the office and I can send it off to you if you want. akaplan@sprezzatura.com [url=http://www.sprezzatura.com]Sprezzatura, Inc.[/url] [img]http://www.sprezzatura.com/zz.jpg[/img] [[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=891762CFC881054F852566DB0077CC26|View this thread on the forum...]]