Jump to content

Macintosh Toolbox programming questions


Recommended Posts

Hi everyone

 

A while back I had the idea to begin learning to program, and what better way to do so than with C and the Macintosh Toolbox :) 

 

It's mainly a hobby at this point, and I just see it as a nice bonus to learn some general programming concepts in the process. I've recently moved on from pure C to Toolbox programming – challenging on a whole new level to say the least :) But I'm slowly moving forward.

 

Naturally, tons of bugs and questions pop up all the time, but this far I've managed to fix and answer most of them myself. There is one issue that I'm stuck with however, so I'm reaching out to all of you here for input. (Would this be the best place for these types of questions? Classic mac programming appears to be a little too niche for Stack Overflow, at least :))

 

My question is this: What would be the most convenient way to test if a window has been moved?

 

DragWindow() doesn't return any result; otherwise that would have been ideal. I suppose I could track the mouse position after the call to DragWindow() but I feel there must be a better way to do it.

 

I'd be grateful any of you could point me in the right direction here.

 

I'm using Think C 5 and System 7.1.

 

(More questions will likely follow, hence the plural in the title ;))

Link to post
Share on other sites

Always excited to hear about folks learning the Toolbox in 2020!

 

Check the window’s global coordinates before and after DragWindow(). I think (**((WindowPeek) theWindow)->strucRgn).rgnBBox may give you what you need? Or assuming you don’t use SetOrigin() in your window, just do

 

Point globalTopLeft;

SetPort(theWindow);

SetPt(&globalTopLeft, 0, 0);

LocalToGlobal(&globalTopLeft);

 

and compare before and after. 
 

There’s probably a simpler way checking the portRect or portBits.bounds but I always found it confusing to remember how those work in global coordinates. 

 

Edited by Crutch
Link to post
Share on other sites

Thank you very much for your input!

 

Ah yes, using the window's coordinates makes more sense than tracking the mouse position, of course. I was wondering if maybe there was some toolbox function suitable for this purpose. If not, portRect and portBits is what I feel most comfortable with at this point, and I'm not using SetOrigin() at the moment, so I think I'll just use the portRect for now. I'll definitely put in a reminder to update it in the future though.

 

I'm building a generic shell app, and I'm trying to implement a custom behavior for the zoom box (maximize if window is in its default position, but revert to the default position if the window has been moved by the user). Thus the need to know if the window has been moved.

 

Thanks again!

Link to post
Share on other sites

Talking about classic mac development; is there any thread here or in some other place where new software is announced or published? If not, perhaps that could be something to think about. Maybe a separate page of some kind. I've come across different types of newly written software while browsing the forums here from time to time, but I have no idea what I might have missed.

Link to post
Share on other sites
  • 2 weeks later...

A second question:
 

One of the first small goals of my programming efforts has been to design a control strip module (or just an ordinary an app at this point, since I'm not quite there yet) that can display and maybe also change the current brightness setting for the backlight on my PowerBook 170. My question is: how can I access this value? As I understand it, it is controlled by the .Backlight driver. Any tips would be much appreciated.

Link to post
Share on other sites

Anyone else who have any information about this? Besides the backlight, reading the current system voltage, charging status and processor speed setting would also be interesting.

 

Apart from this old forum post I haven't been able to find any information online or in Apple's documentation:

 

From: http://www.verycomputer.com/26_b44c8af0142c5893_1.htm

Quote

What's in the new ROMs?
Post by Michael Newbe » Fri, 08 Nov 1991 06:58:19

 

I got my hands on a PowerBook 140 yesterday and decided to snoop.

 

/…/

 

The following resources are in ROM on this machine (resources overriden via ROv# are not shown)

 

/…/

 

Type            ID Name Size -------+-----+----+-------------------------------------------------------- /…/
'DRVR'

            4 ".Sony" 26820

           50 ".ATBOOT" 17796         -- new

           49 ".netBOOT"  1988                -- new

           51 ".EDisk"  2500          -- new

        -16511 ".Backlight"    -1     -- new

            3 ".Sound"  2468

          127 ".ENET"   340           -- new

 

By the way, does anyone know what kind of forum this is? Interesting to find an archive of such old posts! Very little information about the site itself though.

Edited by PB170
Link to post
Share on other sites
  • 3 months later...
Posted (edited)

After searching for info about how to access and control the backlight for probably the fifteenth time, the Macintosh Portable development note suddenly appeared among the search results. Clicked it – and found the documentation for the backlight driver! I don’t own a Portable, so it never occurred to me to look for information related to it, but it makes sense of course.

 

Turns out that the backlight is actually controlled just like a device driver, as documented in Inside Macintosh. The system voltage and charging status can also be read using calls described in section about the Power Manager in Inside Macintosh.

 

During the time that has passed, I’ve been busy learning how to write control strip modules, and a few issues/questions have turned up along the way…

 

My original intention was to use a pop up slider to control the backlight, using the SBTrackSlider routine described in the control strip documentation. However, I haven’t been able to get it to work properly. The slider appears as expected but returns all kinds of random values. Still being a newbie programmer, I suspected I made some mistake in my code, and spent a lot of time troubleshooting it and examining the values returned. Without getting any further, I tried to move the module over to OS 9, and discovered that it works just as it should there, which makes me wonder if there’s actually a bug in the implementation of SBTrackSlider in earlier versions of the Control Strip. Seems odd, considering that it’s a very basic call and that it’s described in the original documentation. But the fact that the included sound volume control strip uses a pop up menu with numbers on System 7 and a slider on OS 9 might be a sign of that. Anyone who knows?

 

Following the lack of success with the slider, I decided to implement a popup menu instead. However, the when the module is clicked, the menu appears as in the attached video.


I vaguely recall seeing this behavior in other places, so maybe this is just how menus that don’t fit on the screen work? But is there a way around it?

Right now I’m kind of stuck, since neither of the menu options work properly.

 

I’m thankful for any suggestions :)

 

Edited by PB170
Link to post
Share on other sites
  • 2 weeks later...

No brilliant old school programmers who can help me out here, or point me in the right direction? :)

 

I would prefer if it was possible to get the slider to work, but if it's actually a bug, and it's difficult to get around, making the popup menu appear correctly would be okay too.

 

Right now I'm stuck, so I'm thankful for any input I can get :)

Link to post
Share on other sites

I’ve never used the slider control (didn’t do much development after System 7.1) so can’t help you there. Is SBTrackSlider a system trap I assume? Have you used Gestalt() or similar to confirm it exists before calling it?
 

Is your concern that the pop up menu items populate slowly, or something else? It looks like it’s working correctly?

Edited by Crutch
Link to post
Share on other sites

All of the functionality is provided by the Control Strip extension / control panel, I believe (all functions prefixed with "SB" (short for "Status bar", which was the Control Strip's original name), as described in the Control Strip documentation). Also, the slider appears correctly. It's just that the values that it returns makes no sense (unless the module is moved over to OS 9, where it works correctly).

 

My issue with the pop up menu is the long empty region that appears above the values when it first appears, as shown in the video.

Link to post
Share on other sites

I get it now - I misunderstood your video, though it was just taking a while to populate but now I see that you have to drag the mouse cursor off the bottom edge to get the thing to scroll to the text items.  That's not right.

 

Want to share your popup menu code?

Link to post
Share on other sites

The code that I'm using is just a copy of the code for the sample control strip provided in Apple's Control Strip development kit. It too uses a function provided by the control strip environment (SBTrackPopupMenu). The only thing I've changed is the number of items in the MENU resource.

 

I just tried moving it over to OS 9, and the problem remains there, so if it's a bug it wasn't fixed. But like I wrote, I vaguely recall seeing this behavior in outer places, though I'm not sure about it.

 

The function call looks like this:


menuItem = SBTrackPopupMenu(statusRect, gb->configMenu);

 

where menuItem is a short, statusRect is the module's display area, and configMenu a MenuHandle for the MENU to be displayed, all unchanged from Apple's sample.

Link to post
Share on other sites

Out of curiosity: What kind of values does the control strip module return? Are they of the same type, within a certain range but random, or is it just a complete mess?

The only other control strip module that uses a slider is probably the volume control?

I wonder if there are any source code or examples available on this topic on some of the Apple programming CDs from the early 90s?

Link to post
Share on other sites
Posted (edited)

The values returned are negative, sometimes apart from the first time a selection is done, when they occasionally are positive but mostly negative and always different from the following selections (should be positive), which first had me believe it had something to do with unmatching data types. But the values decrease exponentially, and are also somewhat random (mostly constant, but sometimes change unpredictability between restarts) (again, only on System 7 – it all works fine on OS 9).

 

For example, selecting “52” in a 0–52 range might yield “–137” (or occasionally “52”) the first time a selection is done, and then “–131” after that. Selecting “1” might yield “–2”, “5” “–12” and so on. Selecting “0” always returns 0. With a smaller range, the values returned are correspondingly smaller. As soon as a negative value/setting is stored, the Control Strip refuses to display the menu. 

 

When I made the tests in the beginning of April, I recall the values also adding up, but I’m not entirely sure about that now, and I’m unable to repeat the behavior.

 

Regarding the volume control strip module, what’s interesting is that it uses a slider in OS 9 but a pop up menu in System 7 :)

Edited by PB170
Link to post
Share on other sites
Posted (edited)

I just discovered that if the control strip is aligned to the very bottom of the screen, or one pixel above, the pop up menu appears correctly. If it’s located more than one pixel above, the menu appears as in the video. Obviously some kind of bug.

 

Unfortunately, all versions of the Control Strip that I’ve tried (1.1, from the development kit, and 1.3.1 from System 7.5 and System 7.6) behave in the same way, so I’m kind of out of 68k versions to try :(

 

I guess what I’m primarily looking for now is some mention of these issues in some developer documentation or version history from the time, and possibly some ideas about how to get around them.

Edited by PB170
Link to post
Share on other sites

Thanks for the links! I've been learning to program with the mac toolbox for quite a while now but I've been completely unaware of the existence of that magazine. What a wonderful resource! Programming on classic Mac OS suddenly feels like a much less disconnected endeavor :) Thanks!

 

Unfortunately, and surprisingly, there's not a single instance of the phrase "control strip" in any of the issues…

 

After my previous post, I started to download some of the Apple Developer Connection CDs, which I also learned about quite recently. The Control Strip development kit appears for the first time in the Jan '96 issue, and also in the issue from Oct '98 – with the same version, and the same technical note. One would think the problem with the slider would have been covered by then… Very odd. Perhaps I'm the first one to try it…? :) Or maybe there's something wrong with my setup, or my code. But I can't see what that would possibly be… I've tried it with System 7.1.1 , System 7.5.3 and System 7.6. All return the same negative values, and on Mac OS 9 it works just fine.

 

If the values were just constant, perhaps I could remap them to the actual setting. Obviously a very convoluted way of doing it, but…

Do tell me if you have any other ideas.

Link to post
Share on other sites

Thank you!

 

To reduce the potential for error to a minimum, I've gone back to the original code from Apple ("Control Strip Sample", included in the Control Strip development kit) and just added the code for the slider (and commented out Apple's code for the pop up menu).

 

The original project was made for MPW, and is more recent than Think C 5, so I had to make the following modifications to have it compile with Think C 5:

 

• Compile the ControlStripSample.r resource file with SARez so that it can be recognized by Think C 5
• Replace the "icons.h" file included with Think C 5 with the more recent one included with Think C 7

 

Here's an excerpt of the code, with my changes highlighted:

Quote

#ifndef  SystemSevenOrLater
#define  SystemSevenOrLater    1
#endif

#include <Memory.h>
#include <Menus.h>
#include <Quickdraw.h>
#include <Resources.h>
#include <ToolUtils.h>
#include <Types.h>
//#include <Icons.h>
#include "Icons.h"

#include "ControlStrip.h"
#include "ControlStripSample.h"


/…/


typedef struct Globals {
    Handle            lastIcon;
    Handle            firstIcon;
    Handle            secondIcon;
    Handle            thirdIcon;
    PicHandle        popupArrowPicture;
    Handle            helpStrings;
    short            helpStringIndex;
    short            whichIcon;
    MenuHandle        configMenu;
    short           sliderSetting;
} Globals;


/…/


long HandleMouseClick(Globals *gb, Rect *statusRect) {
    short            menuItem;
    long            result;


    result = 0;

    gb->sliderSetting = SBTrackSlider(statusRect, 53, gb->sliderSetting);
    

/*
    SetItemMark(gb->configMenu, gb->whichIcon, sdevMenuItemMark);

    menuItem = SBTrackPopupMenu(statusRect, gb->configMenu);

    CheckItem(gb->configMenu, gb->whichIcon, false);// uncheck the item for the previous icon

    result = 0;
    if ((menuItem > 0) && (menuItem != gb->whichIcon)) {

        gb->whichIcon = menuItem;
        GetCurrentIcon(gb);
        result = 1<<sdevNeedToSave;
    }
*/

    return(result);
}

 

/…/

 

And here's Apple's documentation about the slider routine:

 

SBTrackSlider.png.f50e7abadc6cea7870f8de64f0a0f548.png


And finally, a .sit file with Apple's original project, and my modified version:

Control Strip test.sit

Link to post
Share on other sites
Posted (edited)

Hmm… I discovered just now that while the module with the slider that I included in the archive works more than the first time a selection is made in Mac OS 9 just like in my previous tests, it stops working after playing around with the slider for a while. However, if I change the ticksOnSlider parameter from 53 (the value I used in the file in the archive) back to 32 (which is what I've been using in my test up till now), it seems to work properly in OS 9 again.

 

Don't know what to make of this… Probably a good idea to have someone look at my code… :)

Edited by PB170
Link to post
Share on other sites

Are you sure that gb->sliderSetting is valid when you call SBTrackSlider()?  What happens if you always use an initial value of 0?

 

Are you sure that moduleRect is correct when passed into SBTrackSlider()?  (Actually this was my first thought when you mentioned issues with the popup menu also.)

 

Are you sure that gb->sliderSetting is actually coming back from SBTrackSlider() incorrectly — is it possible that some later point in your code is overwriting it somehow?  Not sure how you’re debugging this.  Do you know how to use Macbug?  It would be interesting to see what’s happening inside the call to SBTrackSlider().

Link to post
Share on other sites

I haven't had the time to delve into Think C's debugger or Macsbug yet so I'm currently not using them (still a beginner…), but it's definitely on the top of my list of things to learn more about.

 

But the code is straight from Apple's example, so I assume everything is set up properly.

 

Regarding your first point, I realize now that I forgot to initialize sliderSetting to 0 when I went back and modified Apple's example. It is however initialized properly in all of my previous tests, with the same result.

 

moduleRect is provided by the Control Strip software, so that shouldn't be a problem I think. And sliderSetting is only used where SBTrackSlider() is called.

 

Would you mind taking a closer look at the call to SBTrackSlider() for me, if it's not too much trouble?

 

By the way, as I understand it, Think C's debugger cannot be used with code resources like this, where the code is only running when called by the Control Strip software. It it easy to do with Macsbug?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...