robt@molihp.UUCP (Robert L Thurlow) (05/23/86)
I have been playing with a friends' development kit for a couple of days and have had some problems. To learn about the RCS, I made a resource with one dialog box and a small program to listen to it with EVENT_BUTTON. The dialog box is set up like this: --------------------------------- | --------------- | | | Test dialog | | | --------------- | | --------------------------- | | | | | | | -------- -------- | | | | | Yes | | No | | | | | -------- -------- | | | --------------------------- | | --------------------------- | | | Exit | | | --------------------------- | |-------------------------------| The 'Yes' and 'No' are BUTTONS with the RADIO_BUTN flag set, and the 'EXIT' is a BUTTON with DEFAULT and EXIT flags set. All three of these are also SELECTABLE. The 'Yes' and 'No' are also 'children' to the BOX enclosing it, so the RADIO_BUTN flag should mean something. But I have troubles. 1) I have to have code to explicitly darken and lighten the 'Yes' and 'No' buttons with OBJC_CHANGE or else nothing happens. Am I misunderstanding the idea of radio buttons? I thought they would do this visual feedback for me. What is the use of the RADIO_BUTN flag? 2) The 'Exit' must be selected with a mouse click. The 'Return' key is always ignored. I *KNOW* this works in other programs; any ideas on what I am doing wrong? Do the EXIT and DEFAULT flags fight? 3) The RSRC_LOAD works fine, and fails as it should if the .RSC file is not found. I then do a FORM_ALERT to complain, and after accepting the abort option, I do a V_CLSVWK and an APPL_EXIT. The screen is then filled with randomly positioned flickering checkmarks and the system goes off to la-la land, requiring RESET. I don't know what else I must clean up to avoid this; any ideas? (It is a nice effect, though. :-) ) I then tried to get a good stand-alone example that is clear without the RCS. I saved a copy of my resource with the 'Output' option set to 'produce a .C file' to get the data structures, and added this to my code. The RSRC_* routines went away and my OBJC_* functions now apply themselves directly to the "OBJECT rs_object[]" array. Then I tried it. 4) The dialog box now comes up tiny, about the size of a matchhead. None of the features are visible, unless you have a great imagination. It is possible to hit the 'Exit' button, but it takes great talent. And hitting the 'Exit' button is the only way out, remember. Turns out the numbers are too small for all of the objects in the structure; they are in CURSOR coordinates, not PIXEL coordinates like I want. So are they stored differently in a loadable resource file? If so, why the difference? If not, what changes them to pixel coordinates whan I load/use the resource? Obvious solution: translate all the coordinates to PIXEL coordinates. I tried this two ways: I got out my hand calculator and multiplied each x and width by (640/80) = 8, and each y and height by (400/25) = 16, and then I tried the RSRC_OBFIX routine on each member of the array on startup. Both approaches caused the same results, leading to ... 5) The BOX and BUTTON outlines are drawn first, with the text I expect being changed to gibberish. Then in from both sides come two great sweeps of grey, which blotto the boxes when they meet in the center. Then where the old 'Yes' box was supposed to be darkens and the areas where the 'No' and 'Exit' boxes were supposed to be lighten, as the initial OBJC_CHANGE calls take effect. Finally, the mouse cursor appears. Then I can poke at where the boxes were and get them to darken and lighten, just like before, except there are no outlines or text. (This, too, is a nice effect.) Any help on how this stuff works would be appreciated. So would help on what changes to make to incorporate and use the .C output file from the RCS. I post a summary of any mail. # UUCP : ...!ubc_vision!molihp!robt Robert Thurlow # # My thoughts are my own, and are void where prohibited by law. # # "There was something fishy about the butler. I think he was a # # Pisces, probably working for scale." -Nick Danger, 3rd Eye #
robt@molihp.UUCP (Robert L Thurlow) (05/26/86)
I made some progress with my problem over the weekend. Turns out that the '.C' output of the RCS does not do a complete job at filling in the structures. When it wants to install a pointer to *rs_strings[5] in the rs_object[] array, it puts a '5L' as a place marker - period. This is just a reminder to the user to fix things up properly, and if you don't go and do it, you're screwed. All those funny pointers cause lots of problems for the OBJC_* routines! Also, I lied : the RSRC_OBFIX does not fix the rs_object[] entries to PIXEL coordinates, it just screws up the program. So now I am disappointed in the RCS. If it will produce a '.C' file at all, it should do it right. It would be simple to write a filter to fix the output, since the rules are quite simple, so it should also be simple to do it right. It should also put out PIXEL coordinates. With the limitations in the linker and compiler, I suppose this isn't so awful, but it is so GREAT in other ways that this fix would be nice. I'm still having trouble with radio buttons and default/exit, though. # UUCP : ...!ubc_vision!molihp!robt Robert Thurlow # # My thoughts are my own, and are void where prohibited by law. # # "There was something fishy about the butler. I think he was a # # Pisces, probably working for scale." -Nick Danger, 3rd Eye #