Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

OI Crashes on a network system

I dont know if this is realted, but one of the changes I did was to setup SRP.DirectConnect.1 and SrpSyncserver

SrpSyncserver.exe running on the server

MAINMENU (MDI)with ole control with SRP.DirectConnect.1
that messages get sent to

Screen that could be open with multiple copies with ole control with SRP.DirectConnect.1
that receives messages

Most workstations are reporting intermittant (mostly when idle) ' Openinsight stopped working'

Here is a what is on the event viewer for at least 2 crashes.
Are you able to shed any light. Is there something I have forgotten to do or known issues.

- System

- Provider

[ Name] Application Hang

- EventID 1002

[ Qualifiers] 0

Level 2

Task 101

Keywords 0x80000000000000

- TimeCreated

[ SystemTime] 2017-02-27T23:22:00.000000000Z

EventRecordID 2005526

Channel Application

Computer TS12.parsons.local

Security


- EventData

OINSIGHT.exe
9.4.0.0
4f9c
01d291428cb029ee
22
\\Dc\oi7parsons\OINSIGHT.exe
88089f6b-fd43-11e6-80fd-000c292d3ba0


55006E006B006E006F0077006E0000000000


--------------------------------------------------------------------------------

Binary data:


In Words

0000: 006E0055 006E006B 0077006F 0000006E
0010: 0000


In Bytes

0000: 55 00 6E 00 6B 00 6E 00 U.n.k.n.
0008: 6F 00 77 00 6E 00 00 00 o.w.n...
0010: 00 00 ..

«1

Comments

  • Unfortunately that doesn't help me shed any light. What prompted you to think that the crash is related to these products? Did you recently implement them and that's when the crashing began?
  • Yes I did, yesterday.
  • I see. Well, the information provided still isn't all that helpful. I also could not understand what this sentence really means:
    Screen that could be open with multiple copies with ole control with SRP.DirectConnect.1
    that receives messages
    Can you please elaborate?
  • menu option opens a form for data enquiry/entry they can then open the same form again for a different ID and therefore have the same form open twice or as many copies as they like.
  • Because they are the same form, each form opened will have a ole control with SRP.DirectConnect.1 on it.
  • So there is only one form with the SRP DirectControl control (MAINMENU) rather than multiple forms?
  • No. The 1 form that isopened (can be multiple times) have the direct connect control as well as the MAINMENU.
    Sorry I am not explaining well.
  • The MAINMENU has a SRP DirectControl control

    Form FUNERALS_ETY has SRP DirectControl control of which mutiple copies of that form can be opened.
  • As they say, a picture is worth a thousand words. I don't believe this should be a problem, but why do you have multiple SRP DirectConnect controls running in a single application? How does this benefit your application to have multiple controls?
  • FUNERALS_ETY is opened from MAINMENU
  • ....as start_mdichild
  • All the screens that are opened can receive a message and update the data on the screen.
    Why, is there another way to do it. How does the screen know to receive a message and process it if srpdirectconnect is not on that screen.
    Sounds like I have missed something here, which, as you know is not unusual for me.
  • Multi user application.
    A change can be made on another screen is a seperate system, same OI, that affects the data being viewd on this screen.
  • I could try removing it, I dont think the 'datafield' update live, is a big deal.
  • What you are doing is not wrong, but the original intent of the control is to have one residing on a master window. You would then create a messaging system (not unlike a web request/response) that would contain all the metadata and payload data necessary. So, the metadata would contain the target form you want to update and the payload would contain the data that needs to be updated. Then you just have to worry about one event handler on the master window rather than separate event handlers on multiple windows. This will also reduce your memory footprint which is always a good thing.
  • But then you need to find all the open forms to to see if any of them match your target form 'update'.
    Can you then do a send_event'CALCULATE" to a form, outside of that form.

    Is this sounding right
  • Aren't you already doing some kind of matching to make sure the right Key ID is loaded? I guess I don't know what kind of updating you are doing. I thought it was based on the record loaded in the window.

    Nevertheless, once you have the Window ID, you can do anything to that window from outside the form that you can from within the form.
  • But I need the window (matching the key loaded), to do internal processing like refreshing the data and highliting changes, which is why it just seemed so easy the have srpdicrectconnect on the scree.
    Gets message, Oh am I funerals_ety, yes I am, Ok what do you want me to do.

    So, if I dont have srpdiectconnect controlling it, do I use maybe omnievent, but I would still need a list of all running windows in the 'controlling' routine called by the srpdiectconnect on the mainmenu. With srpdirectconnect I didnt, it just analyse all the data thrown at it and processed accordingly. Which I thought was part of the whole concept.

    I really this I am now totally confused as to how I am supposed to do what I want to do. Tell a screen something has changes and to process that change an refresh the data where needed on the screen.!!
  • The explanation of what you are trying to do is too confusing for me to follow. Outside of the crashing (whose source has yet to be determined...we got sidetracked), just continue with what you have been doing since it works for you. Try to see if you can just keep one window with the SRP DirectConnect control running and see if it crashes. If it doesn't, then run a second window, then a third, etc., until it seems to routinely crash on you. There may be a "magic number" that is causing your problems.
  • OK we have now narrowed it down (I also had crashed under this situation), I really hope I can explain this.
    There is a shortcut that opens MAINMENU there is another shortcut that opens MORTUARY_MENU, both menus have srpdirectconnect. If you open both on the same PC:- On MORTARY_MENU you open a 'action screen' that has srpdirectconnect, which lists a number of funerals. You make a change on a funerals_ety screen called from the MAINMENU which then sends a message to to MAINMENU to broadcast a change. That broadcast message is picked up by the action screen srpdirectconnectcontrol on the 'action screen' (open under MORTARY_MENU ) and the info on the screen is updated. Make a few changes like that and the crash happens, if each on separate PCs it doesn't.
  • The routine I have written is called from the FUNERALS table mfs. The routine does a Send_Message(MAINMENU:".OLE_DIRECTCONNECT", "OLE.Broadcast", Message) the srpdiectconnects on the forms have tis in the commuter ole event:
    OLE:
    begin case
    case cp _eqc 'OLE_DIRECTCONNECT'
    begin case
    case param1 _eqc 'OnMessage'
    .
    .
    .

    Which is still why I thought you have srpdirectconnect on each window that needs to process an 'OnMessage' event
  • >>OK we have now narrowed it down (I also had crashed under this situation)

    I did tell them not to do it, but they saw it as a quick way to test!!

    I am going to get their enginers to get what they can and send to microsoft to be analsed, or what ever they do.
  • I will work on putting a document to-gether with screen shots and code samples so you can check what I am doing.
    I have gone over my explanation and it worries me somewhat that you don't understand which sort of leads me to believe I am doing it wrong, but, i cant thing of any other way.
  • Barry - I doubt it is anything you are doing wrong. I think it is more just me having a hard time following your explanation. Screen shots and code snippets would be valuable.
  • OK, I hope you are ready for this.
    I got the event viewer application logs sent to me by the support IT people.
    So I thought I would make it crash to compare logs.
    Opened both menus , saved changes quite a few times, NO CRASH.
    What change had I made, Ah yes removed the srpdirectconnect from the funerals_ety screen.
    Put it back on and it crashed.
    BUT what I was too embarrassed to tell you was that there was actually NO OLE event action on the control.
    Weird, does this sound like something that could happen in this situation - say loops looking for an ole event.
  • edited February 2017
    I would have thought that you would have a single DirectConnect control on the MDI, fire the message at all open MDI child windows and if it matches the ID of a record in an open window, do something with the data in that window otherwise ignore the message?

    in your current instance, if you had 5 windows open the server would be broadcasting 6 copies of the data to that single instance...
  • That does not sound like anything I would consider to be a problem. Since I have not seen your problem before and since this might very well be unique to your configuration, my suggestion is to see if you can create a much simpler application where the crash still occurs. If you get this far, then package that up in an RDK and send it to to support@srpcs.com. Make sure the RDK is self-sufficient. That is, it contains all dependent forms, routines, and inserts. Do not make this databound. I should be able to install the RDK into a target application and run it out of the box.
  • Aaron.

    The srpdirectconnect on the MENU is the one doing the 'broadcast' the others are just 'listening'
    Each window would send to the menu a broadcast rest for it's own ID , not 6 times with the same ID, and anyway it would be only when user saved, so would be delays between.

    >> fire the message at all open MDI child windows
    And how then does the window 'get' the message.?
  • edited March 2018
    uh, probably something along the lines of:

    OnMessage: ************ messageData = "MFS~UPD~12345"; // as example ret = Utility ('OBJECTLIST', 'MY_MDI', 'WINDOW'); // get all open MDI children For X = 1 to DCount(ret, @fm) Call Post_Event(ret<X>, "OMNIEVENT", messageData); // or Send_event() Next // then in the windows even something like: If Field(message, "~", 1) = @window then if field(message, "~", 2) = get_property(@window:".ID", "TEXT") Then if Field(message, "~", 3) = "U" then Send_Event(@WINDOW, "READ") end end

    do the post eval of the messages in the forms event that way any message can be sent to any window and only the relavent windows will listen...
Sign In or Register to comment.