Question on widgets for classic mac os

[rlawson]

So I'm doing the ThinkC study group over at tinkerdifferent (Mac C Programming primer is the book). it's a load of fun.
But I have a question. The basic widgets that come out of the box seem very limited (menus, buttons, text boxes).

What did mac devs back in the day use for things like - displaying sortable tables, progress bars, custom widgets.
I'm imagining there is a piece I am missing. Right now all our examples are of the flavor - draw some text or graphics on the main window and maybe pop up a dialog with some widgets on it.

 

[Crutch]

In the Mac C Programming Primer era, you mostly are on my own my friend!

For sortable tables, you can use the List Manager, but everything beyond basic display and scrolling of the table contents (including any sortability implementation) is on you.

For custom controls, the standard approach would have been to write your own CDEF (control definition function resource). See the Control Manager chapter of Inside Macintosh Volume I. This is a nontrivial exercise though.

For progress bars, one would probably just use QuickDraw to draw and update the thing on the screen, or implement a custom draw procedure for a dialog box userItem. See the section on ”user items” in the Dialog Manager chapter of Inside Macintosh Volume I (the upshot is, you use SetDItem and replace the handle argument to that trap with a pointer to a procedure you want to draw the item whenever appropriate).

Some of these types of widgets may have been supported by either MacApp or the THINK Class Library, the two primary development frameworks that emerged by the early ‘90s, but I didn’t use either much myself and don’t think that’s the direction you want to go anyway.

 

[rlawson]

Ok thanks! And as far as placing controls on the main window - I would make toolbox calls (like to ListManager)?
I have been using ResEdit to design Dialogs which is slightly visual basic like. But I don't suppose that similar thing exists for the main window?

 

[Phipli]

Ok thanks! And as far as placing controls on the main window - I would make toolbox calls (like to ListManager)?
I have been using ResEdit to design Dialogs which is slightly visual basic like. But I don't suppose that similar thing exists for the main window?

ResEdit does windows as well as dialog boxes.

 

[rlawson]

Right - but I didn't see a way to place controls graphically on it like the DITL editor on dialogs

 

[Phipli]

Right - but I didn't see a way to place controls graphically on it like the DITL editor on dialogs

You're testing my memory... was... it done the same way as with a dialog box, effectively loading a dialog style layout into the window?

Sorry, I'd forgotten it wasn't obvious. Crutch will do a much better job at answering than me.

 

[Crutch]

You can just make it a dialog box. The DLOG resource editor lets you use any window definition proc you want, including one that looks like a standard document window. You can go ahead and use that and drop controls wherever you like.

Basically, think of a DLOG resource as just a way to combine (any type of) window with a list of things you want to be prepopulated in the window on load (stored in the corresponding DITL resource). It doesn’t have to represent a “dialog box” really.

Just keep in mind that your “window” is now really a dialog box — you would display it using GetNewDialog, etc. You could then (if you want) use IsDialogEvent and DialogSelect for event handling and just treat it as if it were a modeless dialog box (which is really what it is) — or, you could handle events yourself and use FindControl, TrackControl etc. on a mouseDown exactly as if you’d added the controls yourself with NewControl.

Just remember to draw the dialog items with DrawDialog, and that if it’s a resizable window with scroll bars, you have to move and resize the scroll bars yourself anytime the window size changes.

 

[rlawson]

ahh ok I see. I couldn't get my mind past the dialog being something that shows up when you need confirmation from the user.
But just make it the whole window. Got it - thanks!

 

[oldmacuser]

So I'm doing the ThinkC study group over at tinkerdifferent (Mac C Programming primer is the book). it's a load of fun.
But I have a question. The basic widgets that come out of the box seem very limited (menus, buttons, text boxes).

What did mac devs back in the day use for things like - displaying sortable tables, progress bars, custom widgets.
I'm imagining there is a piece I am missing. Right now all our examples are of the flavor - draw some text or graphics on the main window and maybe pop up a dialog with some widgets on it.

Interesting. Please do tell more about the study group if you don’t mind sharing!

 

[rlawson]

Yeah it's a hoot. Each week you do a chapter and there is a forum thread for each week. That allows people to drop in and start whenever and you just post screenshots/questions/code to the thread corresponding to the chapter you are on. Others that have already done it answer questions/encourage. It's fun. I develop in Java/Python professionally atho I did C for a few years 20ish years ago so it's fun for me to go back to basics.

TinkerDifferent

A community of tinkerers dedicated to vintage computing.

tinkerdifferent.com

ThinkC - [Study Group 0] Getting your Development Environment Setup & Hello, World!

Welcome to the FIRST Study Group Getting your Development Environment Setup & Hello, World! Remember if you're not ready to start this week, don't worry, just come back when you are, we'll still be here to help! Our goals for this week: Setup your environment Start reading Chapter 1 & 2 of...

tinkerdifferent.com

 

[Crutch]

(Right here on 68Kmla is also a great place to get your vintage macOS dev questions answered, of course!)

 

[oldmacuser]

Yeah it's a hoot. Each week you do a chapter and there is a forum thread for each week. That allows people to drop in and start whenever and you just post screenshots/questions/code to the thread corresponding to the chapter you are on. Others that have already done it answer questions/encourage. It's fun. I develop in Java/Python professionally atho I did C for a few years 20ish years ago so it's fun for me to go back to basics.

TinkerDifferent

A community of tinkerers dedicated to vintage computing.

tinkerdifferent.com

ThinkC - [Study Group 0] Getting your Development Environment Setup & Hello, World!

Welcome to the FIRST Study Group Getting your Development Environment Setup & Hello, World! Remember if you're not ready to start this week, don't worry, just come back when you are, we'll still be here to help! Our goals for this week: Setup your environment Start reading Chapter 1 & 2 of...

tinkerdifferent.com

Thank you! This is wonderful!

 

[oldmacuser]

(Right here on 68Kmla is also a great place to get your vintage macOS dev questions answered, of course!)

Of course! Will do!

 

[rlawson]

(Right here on 68Kmla is also a great place to get your vintage macOS dev questions answered, of course!)

Yes I can see you are more knowledgeable than most (all) of us in the study group. Thank you for the help!

 

[Mu0n]

For custom controls, the standard approach would have been to write your own CDEF (control definition function resource). See the Control Manager chapter of Inside Macintosh Volume I. This is a nontrivial exercise though.

For progress bars, one would probably just use QuickDraw to draw and update the thing on the screen, or implement a custom draw procedure for a dialog box userItem. See the section on ”user items” in the Dialog Manager chapter of Inside Macintosh Volume I (the upshot is, you use SetDItem and replace the handle argument to that trap with a pointer to a procedure you want to draw the item whenever appropriate).

Some of these types of widgets may have been supported by either MacApp or the THINK Class Library, the two primary development frameworks that emerged by the early ‘90s, but I didn’t use either much myself and don’t think that’s the direction you want to go anyway.

Nice thread exactly on point in what I find myself needing today.

I'm working on an app called FireJam that lets you use these inputs:

* Typing keyboard
* MIDI in (possible thanks to a great quality help I got from here in 2024)
* Mouse click and hold

Leading to these outputs:
* MIDI out
* All 3 variants of the Sound Driver
* Hopefully a real time mix of the freeform buffer with polyphony

My current wish is to reverse highlight the note graphics as they are interacted with and i thought I'd make a Code Resource of a note shape in a rectangle. I read and tried to dig in these materials:

* Original Inside Macintosh vol 1
* Later inside macintosh : control manager
* Think C primer vol 1 and 2
* Ultimate Mac Programming

None carry you all the way with all the steps needed in both ResEdit and Symantec C++ 6.0 which I'm using.

I know I have to:
* Set the project type to code resource
* Set the signature type to either CODE or CDEF
* Set the main function as pascal long main
* Deal with a switch with a short variable to deal with all cases associated with controls
* Add the built resource to my main project's resource fork either as a CDEF directly or a CODE
* Use a ControlHandle with a procID of 16*CDEF_id + variantNb

After all is said and done, I should have 7 rectangles representing my crude octave (white notes only for now) but all I get is a large rounded rectangle surrounding the area I wanted my first test in, as if it reverted to a single normal button.

Questions:
1) must I build a CODE and then resedit-make a CDEV with 0000 0080 (to link it to is 128) or do I build a CDEV directly?

2) should I have used empty text labels with programmed click behavior and bypassed all this mess instead to get my rectangular shapes? And call a FrameRect on their updating?