Macintosh Toolbox programming questions

[PB170]

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 )

 

[Crutch]

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. 

 

[Crutch]

.... curious why you need to do this though. DragWindow() will move the window for you, of course. What else do you need to do after it’s moved?

 

[PB170]

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!

 

[PB170]

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.

 

[PB170]

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.

 

[gobabushka]

It should be a value set in the PRAM. As for how to set or change it, that im not sure.

 

[PB170]

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

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.

 

[PB170]

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


View attachment Popup_menu.m4v

 

[PB170]

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

 

[Crutch]

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?

 

[PB170]

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.

 

[Crutch]

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?

 

[PB170]

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.

 

[John_A]

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?

 

[PB170]

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 

 

[PB170]

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.

 

[John_A]

Well, I would probably dig through the Apple Developer magazines from that time. You might find something in there.

https://vintageapple.org/develop/

 

[John_A]

Don't know if you have this technical note.

https://www.fenestrated.net/mirrors/Apple Technotes (As of 2002)/os/os_06.html