Jump to content

PB170

6502
  • Content Count

    118
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

523 profile views
  1. Thanks for your input! It's easy to overlook even simple stuff so any ideas are appreciated. While developing the CDEFs, I've been using using a simple test app that just calls GetNewDialog/ModalDialog and loads a DLOG with the control in it, and at this point everything is working fine there. I also have a more proper app with a window, menus etc. that I've been using as a shell for various test projects. The first CDEF (with the buttons) worked just fine when I tried it (but doesn't use offscreen graphics). The current CDEF (for sliders) works perfectly as long as off
  2. So, any further ideas? What could be the reason for the offscreen graphics failing in the app? And what's the right way to set up action procedures?
  3. Just realized that I had the pen set to white in the app. Kinda hard to see against a white background The text shows up in the app too.
  4. Just realized that I had the pen set to white in the app. Kinda hard to see against a white background The text shows up in the app too.
  5. I'm sorry, it's getting a bit late here… That could of course be a clue. I'll look into it tomorrow
  6. Yes, FindWindow() followed by FindControl() and then TrackControl(). I'm just reusing the code from the calculator I mentioned above, where it works fine. I've also used it successfully with other projects, so it should be relatively free of errors. The CDEF responds to testCntl by returning inThumb (129) if the mouse click was in the thumb and 0 if it wasn't. When the CDEF gets a dragCntl message it calls the local Drag_Control() function which calculates the thumb position and calls SetCtlValue() (which sends a drawCntl message) in a loop as long as the mouse is down.
  7. Here's an excerpt from the code with the parts that are handling the offscreen graphics. #include <QDOffscreen.h> void Init_Control( ControlHandle control, globalDataPointer controlData ) { Calc_Bounds_Rect( control, controlData ); GetGWorld( &controlData->currentPort, &controlData->mainGraphicDevice ); controlData->gWorldError = NewGWorld( &controlData->offscreenGraphicsWorld, 0, &controlData->bounds_rect, nil, nil, 0 ); } pascal long main( short var_code, ControlHandle the_c
  8. Wow, that's a quick reply! Thanks! I'm using global variables. Since it's not supported in CDEFs directly, I'm allocating memory for them at startup and storing a handle to it in the control record. The code is a bit messy (and some 1200 lines long…) but I'll clean up and post the relevant parts here to begin with. Regarding the action procs, I've tried all different combinations. I'm using pascal functions, and while I haven't used FlashMenuBar() I'm a frequent user of SysBeep() . This far it appears the code never gets executed. Here's the last attempt I made:
  9. Why does programming the classic Mac OS have to be so hard!!? I need help. During the past four months, I've successfully developed two CDEFs – one for simple rectangular buttons filled with either text or an image, and one for sliders. During the development, I've done the testing in a basic dialog box (DLOG/DITL/CNTL combo), and then moved on to using the CDEFs/CNTLs in an application using GetNewControl(). This worked fine for the button CDEF (I tried it out by following a modern – and totally unrelated – Swift/Xcode tutorial for recreating the Mac calculator app, se
  10. I should have checked eBay too Tada: Focus Enhancements M2895LL/A Apple Presentation System 15-Pin DB15 RCA S-Video https://www.ebay.com/itm/Focus-Enhancements-M2895LL-A-Apple-Presentation-System-15-Pin-DB15-RCA-S-Video/153412482196?epid=218483773&hash=item23b818b494:g:c5kAAOSwNTVfbnsO
  11. I have no idea, but yes, it does look like some sort of video card. Looks like two display connectors, an s-video connector, a composite video connector and a power connector. Felt like searching the web a bit, and the nearest clue I could find was this page: https://fcc.report/FCC-ID/HOWLTV10056 Same company, same numbers in the product code, same date, and video related. The product description doesn't seem to match, however. No RGB or RF-connectors on the board. But maybe it could be a clue.
  12. I'm using Think C 5.0 on a PowerBook 170 (with a 68882 FPU). I've never touched the compiler settings, but FPU instructions are turned off. Turning them on however doesn't affect the results.
  13. Just a simple C (Think C) question here. Can anyone explain why these two methods give different results? I have a decent understanding of how floating point numbers work in binary (5.67999…) and the problem with rounding during assignments, but I'm surprised that these two methods give different results. Could this be a Think C specific thing, or does it apply to C in general? (When I tried it with some online C compilers, both methods produce 568). Anyone who can enlighten me? float float1 = 5.68; float float2; int integer; Method 1: integer = float1*100; inte
  14. I trust you Thanks for clearing that up. I found it while searching online. Apparently it's in an earlier version of Inside Macintosh, dated 1982–1984. Now that I check it, it's not in the 1985 version that I have saved on my computer. So probably a good idea that got scrapped
  15. Another small update! Sliders are apparently not called sliders, but dials in Apple's documentation. Inside Macintosh mentions them in the following passages (of which the second seems to contradict the first…) (my highlighting):
×
×
  • Create New...