[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

1995.0. "Objects done in both 'C' code and UIL " by FREZEN::PROJECTS () Wed Jan 03 1990 18:19

	I have a menu_bar with 2-3 pulldown menu's. This is all done in UIL.

	I want to add a varying length pulldown menu to this menu bar. To
	accomodate the varying length feature, the code for this pulldown
	menu must obviously be done in 'C'.

	My question is are there any conflicts with beefing up an object
	with 'C' code if it has been initially cast in UIL.

	I'm trying to avoid tearing apart the already big menubar that is done
	in UIL and converting it to 'C'.

	I guess I could better state my question...

	Objects can be created in both UIL & 'C'. Is it legal for them
	to be interleaved and if so is this interleaving 2 way or 1 way.

	Any comments Much appreciated
T.RTitleUserPersonal
Name
DateLines
1995.1Mix and matchLEOVAX::TREGGIARIThu Jan 04 1990 07:445
    You can mix and match UIL and C widgets all you want.  DRM uses the
    same calls to create widgets that you would in C, so the toolkit
    can't tell the difference.
    
    Leo
1995.2UIL/DRM can do it...R2ME2::OBRYANWhen in doubt, let the user decide.Fri Jan 05 1990 02:0131
RE:.0

To amplify what Leo has said in response to
>	I want to add a varying length pulldown menu to this menu bar. To
>	accomodate the varying length feature, the code for this pulldown
>	menu must obviously be done in 'C'.
As of V2 DECwindows, anything doable in C is doable in UIL (in terms of widget
creation.)  A "varying length pulldown menu" is a snap in UIL, particularly
if you know what the "variable" parts of the menu will be.  There are two
ways to go here:
	1) Declare the extra pulldown objects* in UIL, but don't parent
	them to the pulldown menu in question (i.e. don't declare them in
	the pulldown menu's "controls" section).  When you need to make the
	new objects appear in the pulldown, simply fetch them from the UID file.
	(Of course, they will [by default] be added to the end of the menu.)
	2) Declare the extra pulldown entities in UIL, but declare them
	"unmanaged" when listing them in the controls section of the pulldown
	menu.  At run time, simply Manage/Unmanage them as needed.  (This
	method is somewhat less efficient, since the memory for the "invisible"
	objects is allocated whether they are used or not.  However, the cost is
	minimal if you use the "gadget" variant of the object.)

   If (on the other hand) you DON'T know what the "variant" parts will be, you
can declare a "generic" object of the appropriate type in UIL, choosing the
argument/callback values you know all such "variant" objects will need.  Then,
when you are ready to create such an object at run time, use the DRM routine
FetchWidgetOverride on the "generic" object, supplying the "variable"
arguments in the routine arg list.  (This is a variation on scenario 1 above.)

(*)- such as extra push_buttons, pulldown_entries, or toggle_buttons