Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Say I have a colorbar object and an image object and I want to keep their color table and color range the same whenever either of the objects are changed. Also, the colorbar is also positioned relative to the image, so if the image's position changes, the colorbar's should be updated as well. My idea is to store the colorbar as a property in the image. Internally, the image would then add itself the colorbar. When either are updated, trigger updates to the other (would need a flag to prevent infinite loops). With this, the ability to add images to colorbars would have to be a hidden feature in order to maintain the one-way work flow of adding colorbars to images. Suggestions or comments?
Re: How to keep two objects synchronized?
Matthew Argall writes: > Say I have a colorbar object and an image object and I want to keep their color table and color range the same whenever either of the objects are changed. Also, the colorbar is also positioned relative to the image, so if the image's position changes, the colorbar's should be updated as well. > > My idea is to store the colorbar as a property in the image. Internally, the image would then add itself the colorbar. When either are updated, trigger updates to the other (would need a flag to prevent infinite loops). > > With this, the ability to add images to colorbars would have to be a hidden feature in order to maintain the one-way work flow of adding colorbars to images. In the Catalyst Library, one object registers its "interest" in another object. Basically, it tells the object what kind of "message" it would like to receive and adds its reference to the object's "send a message to" container. So, for example, an image would register its interest in a colorbar's Change Colors message. When the colors of the colorbar are changed, the colorbar object looks in its message container to see if anyone is interested. If so, the object calls the interested object's MessageFrom method with the relevant information. It works great. One advantage of this kind of communication is that several images can register interest with, say, a colorbar object, and they will all get updated when the colors change. This kind of messaging infrastructure is built into the CatAtom object, which all objects inherit in the Catalyst Library system. This way all objects can communicate with other objects, even if you can't currently think of anything for them to say. ;-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
Le jeudi 3 octobre 2013 14:49:14 UTC+2, Matthew Argall a écrit : > Say I have a colorbar object and an image object and I want to keep their color table and color range the same whenever either of the objects are changed. Also, the colorbar is also positioned relative to the image, so if the image's position changes, the colorbar's should be updated as well. > > > > My idea is to store the colorbar as a property in the image. Internally, the image would then add itself the colorbar. When either are updated, trigger updates to the other (would need a flag to prevent infinite loops). > > > > With this, the ability to add images to colorbars would have to be a hidden feature in order to maintain the one-way work flow of adding colorbars to images. > > > > > > Suggestions or comments? If you are using COLORBAR and IMAGE functions, this can be achieved by appropriate setting of TARGET, POSITION and RELATIVE keywords in COLORBAR object, each time you change the image data (for instance, by calling the SETDATA method of the IMAGE object). alx.
I just had a look. This is a great idea -- much more straight-forward than what I had in mind. A couple of questions: Say I have a colorbar and an image object and I want them to listen to each other. I would still have to do something like this, right? It seems like there would be an infinite loop here... theColorbar -> RegisterForMessage, theImage, 'ChangeColor' theImage -> RegisterForMessage, theColorbar, 'ChangeColor" If I want to register more than one message, I cannot pass a string array. Instead, I have to register for again. Was there a reason for this? Do you still develop the catalyst library? If not, do you know of any current widget features that are missing?
> If you are using COLORBAR and IMAGE functions, this can be achieved by appropriate setting of TARGET, POSITION and RELATIVE keywords in COLORBAR object, each time you change the image data (for instance, by calling the SETDATA method of the IMAGE object). Thanks for pointing this out!
Matthew Argall writes: > I just had a look. This is a great idea -- much more straight-forward than what I had in mind. A couple of questions: > > Say I have a colorbar and an image object and I want them to listen to each other. I would still have to do something like this, right? It seems like there would be an infinite loop here... > > theColorbar -> RegisterForMessage, theImage, 'ChangeColor' > theImage -> RegisterForMessage, theColorbar, 'ChangeColor" In some cases, you do have to take care not to get in an infinite loop. This is typically solved by adding a NOMESSAGE keyword, of something of the sort, to the method that "changes colors". In other words, just do this, but don't tell anyone about it. Such infinite loop cases are rare in my experience. > If I want to register more than one message, I cannot pass a string array. Instead, I have to register for again. Was there a reason for this? The usual reasons: sloth and lack of foresight. > Do you still develop the catalyst library? If not, do you know of any current widget features that are missing? I keep the Library up-to-date, but I wouldn't say I am actively developing it. I expect a new set of widgets ANY-DAY-NOW and presume this Library will quickly become obsolete. Although given what I have seen of how you have to program a Window() function, I would not bet on simplicity as a feature of the new system when it arrives. :-) One reason I haven't developed the Catalyst Library more is that even it became overly complex over time, to the point where I was having trouble teaching ordinary programmers how to work with it. Instead, I opted to take some of its best ideas (e.g., simple image display, coordinate objects, color and device independence) and incorporate them into the Coyote Library in a way that was more understandable for everyone. Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
David Fanning writes: > One reason I haven't developed the Catalyst Library more is that even it > became overly complex over time, to the point where I was having trouble > teaching ordinary programmers how to work with it. Instead, I opted to > take some of its best ideas (e.g., simple image display, coordinate > objects, color and device independence) and incorporate them into the > Coyote Library in a way that was more understandable for everyone. I was thinking about complexity as I was taking a shower this morning. When I wrote the paragraph above, I was thinking about the Catalyst interactions, which are too complex for most people to program. But, on the other hand, they really are extraordinary. (Interactions allow you to move text around on the display, resize boxes, rectangles, and arrows, change colors and other properties, etc.) I've never seen the like using direct graphics. They make direct graphics manipulations seem like magic. You can see this for yourself in a Catalyst application like AnnotateWindow, which allows the user to add annotations to an image or to a graphics window. That truly was a graphics revolution that no one seemed to want or need. Such is life that often our best work is completely ignored. ;-) http://www.idlcoyote.com/catalyst/annotate.html Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
David Fanning writes: > You can see this for yourself in a Catalyst application like > AnnotateWindow, which allows the user to add annotations to an image or > to a graphics window. That truly was a graphics revolution that no one > seemed to want or need. Such is life that often our best work is > completely ignored. ;-) > > http://www.idlcoyote.com/catalyst/annotate.html Here is a relevant web page today for anyone thinking about doing something creative in IDL: http://www.brainpickings.org/index.php/2013/10/04/the-phanto m-tollbooth- documentary/ Be sure to play the first video, which I think crystallizes the creative process as I know it. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")