2 windows 2nd not getting broadcast

BarryStevens

I have 2 different mdichilds open under the one MDI Menu. One Window sends an OLE.Broadcast the second window is not receiving it. All OK when run in separate MDi. i.e. 2 copies of app running.
There is something in the back of my mind about seeing something about a 'token' id being generated not being unique and thus some are getting 'lost'. (Also asking this question is familiar(sorry))

DonBakke

It just so happens that I was working on a project today that uses the SRP DirectConnect control. I put 5 different SRP DirectConnect controls on the same window and then executed one Broadcast. All 5 controls got the OnMessage event.

Are you sure that each control is connecting to the SRP SyncServer? Are you qualifying each control to listen for the OnMessage event?

BarryStevens

This is a bit different to that.

The directconnect control is on the mainmenu (mdi) . There are 2 windows open. One window sends message (to the directconnect control on the mainmenu) for the other window to 'pickup'. The other window is not picking up, but is, if open in another open copy of the mainmenu.

BarryStevens

Why '5 different SRP DirectConnect controls on the same window'

BarryStevens

Sorry, correction, it does not work if another copy of the mainmenu is open on the same PC, only if open on another PC on the network.

DonBakke

I only did that to test for your issue. I still maintain that multiple SRP DirectConnect controls running in the same app is not the best design...but it should work.

You didn't answer my questions.

BarryStevens

>>Are you sure that each control is connecting to the SRP SyncServer? Are you qualifying each control to listen for the OnMessage event?

'..each control', yes, ....you mean the directconnect(of which there is only 1)?

There is only 1 control that is on the mainmenu, so, yes as it works when on separate PCs on network.
The mainmenu directconnect onmessage event sends a post_event omnievent to all the open windows as was suggested elsewhere in this forum.

But worried I am not explaining properly as your questions are not matching my problem.
If you think that this should work under this situation, then I will put some debugging in to see what is/isnot happening.

DonBakke

I agree, we are talking past each other. However, there are points in your narrative which lead me to believe your setup and implementation is wrong.

BarryStevens

That is what I was thinking. I must have misunderstood the Ideas that were suggested.
If you do understand my senario, how do you suggest this should be setup.
In the meantime I will see if I can find the posting re how to do (I think it might have been Aaron's)

BarryStevens

Looks like I did post it and was unresolved.

https://forum.srpcs.com/discussion/569/oi-crashes-on-a-network-system/p2

Aarons suggestion was here at the bottom:

https://forum.srpcs.com/discussion/569/oi-crashes-on-a-network-system/p1

DonBakke

Aaron's suggestion was really the same suggestion I gave near the top of the entire thread. He just took the time to give you a prototype to work with.

Let's start over since it is clear that there are some misunderstandings and perhaps false assumptions on my part.

Is it now the case that you only have one SRP DirectConnect ActiveX control embedded within the entire application?

If so, does this control lives on your MDI Frame?

In your original post, you said one window sends the broadcast but the other window does not receive it. This is where I am confused. How exactly does the "one window" send the broadcast? Are you invoking the Broadcast method of the SRP DirectConnect control that is on the MDI Frame or are you using the SRP DirectConnect COM object?

How exactly does the "second window" receive the broadcast? If there is no SRP DirectConnect ActiveX control on this window, how does it get notified of a message?

My understanding is that you are trying to use the SRP DirectConnect control as a way for the same OI application to talk to itself. Is that correct? If so, I suggest this is overkill. The SRP DirectConnect control (along with the SRP Sync Server) was designed so that different instances of OI can talk to each other (peer-to-peer). I would recommend a simpler and more direct way, such as Send_Event(), for one OI form to talk to another OI form within the same running application.

BarryStevens

If so, does this control lives on your MDI Frame?

Yes

How exactly does the "one window" send the broadcast? Are you invoking the Broadcast method of the SRP DirectConnect control that is on the MDI Frame

Yes
rv= Send_Message(MAINMENU:".OLE_DIRECTCONNECT", "OLE.Broadcast", Message))

How exactly does the "second window" receive the broadcast?

MAINMENU:".OLE_DIRECTCONNECT:
case OleEvent _eqc 'onmessage' if cp _eqc 'OLE_DIRECTCONNECT' then call mortuary_funeral_directconnect_onmessage(@Window,Param2) end

mortuary_funeral_directconnect_onmessage:
OpenMDIs=utility("OBJECTLIST",MenuName,'WINDOW') count=dcount(OpenMDIs,@fm) for x = 1 to count call post_event(OpenMDIs<x>,"OMNIEVENT",MessageData,'onmessage') Next x

2nd window 'OMNIEVENT:
begin case case param2 _eqc 'onmessage' PassedParam=param1 gosub ProcessOnMessage End Case

such as Send_Event(), for one OI form to talk to another OI form within the same running application.

But that window can also be open by itself in another PC , so I do have to do the broadcast for the second window.
I don't see it being called overkill, more like 'it cant work that way', so you are saying I have too take into account the possibility it is open on this PC and do a send event.? How do I tackle that - - stab in the dark send_events.
What about when 2 instances of the menu running on the same PC, how do you then do it for that, which I assumed should work and dont see why it cant and , would a send_event work?

DonBakke

Thank you for providing the details above. This is most helpful. I am now pretty certain I understand the nature of your problem. You are expecting the same SRP DirectConnect control that sent the Broadcast message to receive the OnMessage event. That won't work. The design of the control is to avoid that exact behavior.

Just to be clear, I am not saying don't call the Broadcast method. As you noted, other instances of OI will need the OnMessage event to sync up. So you are correct there.

To work around this, in your code that sends the Broadcast method, also call this:
call mortuary_funeral_directconnect_onmessage(@Window,Param2)
That will simulate what your form would do naturally if it actually received the OnMessage event.

What about when 2 instances of the menu running on the same PC, how do you then do it for that, which I assumed should work and dont see why it cant and , would a send_event work?

Two instances? Do you mean the main menu is a multi-instance form or are you referring to two instances of the application (i.e., two OpenInsight sessions on the same PC)?

BarryStevens

Your suggestion is noted and will try that.

two instances of the application (i.e., two OpenInsight sessions on the same PC)?

Yes

Are you saying that for correct implementation, that each window should have a directconnect ole and the onmessage should be sent to those.

BarryStevens

that works

call mortuary_funeral_directconnect_onmessage(MAINMENU,Param2)

Thank you so much

DonBakke

Are you saying that for correct implementation, that each window should have a directconnect ole and the onmessage should be sent to those

No, one SRP DirectConnect control per instance of OI is ideal, although I now understand why your original design utilized an SRP DirectConnect control on each window. That would have been the only way for the same instance of OI to talk to itself via the SRP Sync Server. However, as we have already discussed, that is a round-trip to the server that is unnecessary. Also, as you have reminded me, multiple SRP DirectConnect controls in the same instance of OI can cause OI to crash.

that works

call mortuary_funeral_directconnect_onmessage(MAINMENU,Param2)

Very good. The nice thing about this solution is that it still uses the same subroutine call so there wasn't much re-engineering required to make this work.

AusMarkB

multiple SRP DirectConnect controls in the same instance of OI can cause OI to crash

Important little note right there.
I don't have this scenario at the moment but I had coded for the possibility. Now I know not to try and implement it.

DonBakke

Barry was helpful in reminding me that this was previously reported here. However, I believe the subject was glossed over as the conversation turned into a discussion about best-practice architecture. The original issue has been logged although I'm not sure what the prognosis is at this point.

AusMarkB

I see it was an obviously I glossed over (perhaps glazed over) it as well while attempting to understand the actual scenario.
As I said, I haven't implemented the two directconnect controls as yet, nor do I have any immediate plans to but I think where my mind was headed during the initial implementation was this.

I have a directconnect setup for use with a very specific purpose, sending notifications between users, ie the onMessage results in a popup on the desired recipients screen. The most common use of this though is for notification of the completion of batch processing. For example, a user runs a report that is known to take an extended period of time to run. They can opt to batch the report so they can continue with their work. The report gets processed in due time on the server, a file gets created, then the user receives a notification/popup that the report is finished and a link to the actual report.

The thinking behind the second directconnect control was if I had a need to keep other things in sync for example perhaps similar to what Barry is doing or like would be the case with the SRP Schedule. A separate directconnect control. A syncserver running on the server but with a different port. That way notifications could be handled through one directconnect/syncserver and synching could be managed via another combination of the two.
If the OI crashing issue gets sorted do you think there would be any benefit to making the distinction or would it perhaps be overkill?

DonBakke

I have a directconnect setup for use with a very specific purpose, sending notifications between users, ie the onMessage results in a popup on the desired recipients screen. The most common use of this though is for notification of the completion of batch processing. For example, a user runs a report that is known to take an extended period of time to run. They can opt to batch the report so they can continue with their work. The report gets processed in due time on the server, a file gets created, then the user receives a notification/popup that the report is finished and a link to the actual report.

Actually, this was one of the first applications for why the SRP DirectConnect control was created. Previously, we used Remote Engines to emulate this behavior.

The thinking behind the second directconnect control was if I had a need to keep other things in sync for example perhaps similar to what Barry is doing or like would be the case with the SRP Schedule. A separate directconnect control. A syncserver running on the server but with a different port. That way notifications could be handled through one directconnect/syncserver and synching could be managed via another combination of the two.
If the OI crashing issue gets sorted do you think there would be any benefit to making the distinction or would it perhaps be overkill?

At the moment I believe it is overkill but I suppose there could be a good argument for different SRP DirectConnect controls which are plugged into different ports. This might make sense if there is a lot of chatter and perhaps it would make sense if a specific window ignored it simply by not tuning into that port. But for now I find it easier to rely upon a messaging package that is self-identifying. Then each SRP DirectConnect control that receives a message can inspect the package, determine if it is relevant, and route the message as appropriate.

For the project I'm currently working on, I created a service module to facilitate the messaging. Two of the services are SendRequest and SendResponse (borrowing from HTTP request and response messaging). Each service has two arguments: Type and Body. A JSON object is created with the information packaged and then sent out to the SRP Sync Server. In fact, I don't even use the ActiveX control on the form to broadcast the message. I use the COM object so that my messaging service can be called from anywhere at anytime.

Then the OnMessage event handler unpacks the JSON object and quickly checks to see if this is a Request or a Response. The event handler then ignores it if needed or handles it as appropriate. I think your situation could work well in this context since you can add new requests and responses at will.

AusMarkB

The packaging it up as JSON is the magic factor that will make all the difference.
I am following a similar concept but I didn't think to use JSON as the message, probably because at the time I wasn't familiar enough with it. I simply made a string with delimiters. Works but is limited in it's capabilities.
I use both the activex and the COM object depending on the source of the notification.

It will require a bit of a rework but worth it in the end I reckon.

DonBakke

It will require a bit of a rework but worth it in the end I reckon.

Yes, I believe it will be well worth the effort. In a different project (which was inherited from another developer), there was a lot of data being marshaled back and forth via a string...not even with delimiters! Like you, my understanding and appreciation of JSON gave me the incentive to rewrite this using a new payload mechanism. I am sooo glad I did this. Adding new elements to the payload is super easy since I just need to create a new name/value pair....done. No need to reserve specific delimiter positions for specific values and then have to define them somewhere else (like an insert). In fact, it was this earlier project that inspired me to handle my current project this way.

BTW, to keep things safe, I always BASE64 encode the content I am passing in through the Body argument and then decode it on the receiving end.