David: I'll read up on the web sockets - when I first saw that I misread it for "WebObjects". A cold chill ensued.
C_Object is a great addition to the language. Agree that it doesn't do everything that OT does but that why we have wrapper routines. I've extended Cannon's OBJ_Module with OBJ_SetArray_Text/Long/Real and a few other array commands and I can get a lot done with C_Object that I'm doing in OT. The biggest benefits - scope/garbage collection and the content of a C_Object is visible in the debugger. Those are "bloody mavhelous". "you're tossing blocks of code at the end of the thread of control over there for one-off execution." Excellent way to phrase it. And the emphasis is on "over there" because the code executes in the context of the destination form. "execute in form" similar to "execute on client" "On Outside Call was always documented as being unreliable while CALL FORM / CALL WORKER guarantee delivery." OOC worked well form me, as far as I know (emphasis on the "AFAIK"). I did have to tweak my original code to work in a Repeat loop, as you say, Call form/Call worker will always get through so there's no need to jump through hoops (loops) to make sure the message arrived. "NTK's IPC channels easier" - agreed. I"m using an array-based derivative of that approach (taken from ITK about 20 years ago) with a change in 2000-01 and that's it. Highly reliable and zero maintenance but it doesn't allow me to get to a specific form…which is what's needed to get at the * dialog. Very nice to have multiple active windows in a process but disappointing that I couldn't get to it with a message. "You mention that you're doing message routine. This can be pretty darn impossible to trace or debug if there's nothing in the message about the path that it has followed." I only had to chase messages "down a rabbit hole" a few times over the years. Two ways of reducing the odds of that happening - one of the properties of a message will allow the message and its metadata to be displayed added to arrays displayed in a grid. I needed that to debug some code that had become very involved and the end result is that it helped force me to rethink my approach. The other technique that I've used it a bit dated now but was very helpful before V11, back in the dark ages when "Find in design" was dreadfully slow. That situation convinced me to use IP vars in the message. From *MSGIP_Vars_Init*: C_TEXT(<>MSG_InsertCarriageReturn) <>MSG_InsertCarriageReturn:="<>MSG_InsertCarriageReturn" C_TEXT(<>MSG_ProposalIsLocked) <>MSG_ProposalIsLocked:="Proposals_is_Locked" C_TEXT(<>MSG_BringToFront) <>MSG_BringToFront:="<>MSG_BringToFront" C_TEXT(<>MSG_Close) <>MSG_Close:="<>MSG_Close" C_TEXT(<>PROC_Activated) <>PROC_Activated:="<>PROC_Activated" From On Outside call: Repeat C_LONGINT($msgHandle_L) $msgHandle_L:=MSGIP_Message_Get (Current process) C_TEXT($msg_T) $msg_T:=MSGIP_TextMessage_Get ($msgHandle_L;False) Case of : ($msg_T=<>MSG_BringToFront) PROC_ResumeAndBringToFront (Current process) : ($msg_T=<>MSG_Close) CANCEL End case MSGIP_Message_Clear ($msgHandle_L) Until (MSGIP_MessageCount_Get (Current process)=0) To your point about the provenance of the message, another significant argument for an object without which it would be gruesome to try to add that sort of data to…a BLOB?! No interest in the level of mental gymnastics… Time to have a looksee here - http://forums.4d.fr/Post/EN/ 19129127/1/19129128 -- Douglas von Roeder 949-336-2902 On Fri, Mar 17, 2017 at 2:18 PM, David Adams via 4D_Tech < [email protected]> wrote: > > Interesting approach - thank you for posting that. > > DvR: You, of all people, will *love* this approach. > > > Lacking "callers" and C_Object, I've been using On outside call + > > ObjectTools + IP messaging based on the ITK message queuing system. > > Once you have access to V16, you may find: > > * You like C_OBJECT because it's very fast and native. But it won't do > everything that ObjectTools does. > > * You may still want to use IPC channels from NTK. They're traditional > messages, easily support a wider range of messaging patterns, and can be > used to-from anywhere. > > * CALL FORM/CALL WORKER are great! You'll love them. On Outside Call was > always documented as being unreliable while CALL FORM / CALL WORKER > guarantee delivery. (Unless you kill a worker, kill a process, kill 4D, or > crash. But, hey, that's pretty reasonable for a lot of situations.) > > > I'm not sure if this is germane to Call form/worker but I include a > "reply to ID" > > in the message that's sent. > > Yes, that can be entirely relevant. These 'calls' aren't a channel, you're > tossing blocks of code at the end of the thread of control over there for > one-off execution. There is no return message. You can send along callback > details if, for example, you need a result. There are times when you'll > find NTK's IPC channels easier. And, yes, message discipline is _super_ > beneficial. You mention that you're doing message routine. This can be > pretty darn impossible to trace or debug if there's nothing in the message > about the path that it has followed. > > Tip: I've found it helpful to define a 'recipient' object as a specific > type. This can be the recipient of a CALL FORM/CALL WORKER message or the > callback details when you want a result, error, or confirmation message > returned. By treating this as a custom data type, it's easy to have a > single method for creating recipients and for validating them. "Validating" > matters if you, for example, want to be sure that method names exist and > that window refs are valid. > > > My projects are just moving to 15.x now so Call worker/call form are > still > > a bit out of reach for me but I'm glad to see that these have been added > to > > the language. They're a natural outgrowth of OOC, Call subform container, > > etc., and we *finally* have a way to communicate with those windows > opened > > in the asterisk. > > Yeah, you'll love it. Given our existing framework, you'll feel like some > things are missing - so keep NTK around. Also, vote for a native WebSockets > implementation. This would be an *amazingly* great addition to 4D. You > could have a persistent, bi-directional, point-to-point pipe between > processes on one machine or different machines. Game changer. > > WebSocket protocol on 4D webserver > http://forums.4d.fr/Post/EN/19129127/1/19129128 > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** > ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
