🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.windows.open-look
3 messages
3 total messages Started by ctoomey Fri, 22 Jan 1993 13:27
Weird XView 3.0 XV_KEY_DATA problem
#2785
Author: ctoomey
Date: Fri, 22 Jan 1993 13:27
19 lines
1203 bytes
Hi All,
	came across a weird problem with XView 3.0 today. I created a canvas as
a child of a frame and attached 11 items to it's paint window using
XV_KEY_DATA. This worked fine with XView 2.0 but crashed under version 3.0.
The cause seemed was an xv_get(window,XV_KEY_DATA,5) instruction which should
have returned NULL because that item had not yet been set. I tried setting the 
item in advance - now the thing crashed just after the start of the xv main
loop. After many hours poring over manuals and wracking my brains for possible 
causes I tried changing the 5 to a 23. It worked!

	What I'd like to know is why? Is it a mistake in my code (there are 
definitely no other items with this number) or is there an instruction in XView
3.0 like "if key==5 then crash" :-) If anyone has any ideas I'd like to know...

			thanks in advance,

			Colm Toomey

			ctoomey@ccvax.ucd.ie 
Re: Weird XView 3.0 XV_KEY_DATA problem
#2792
Author: The Tankster
Date: Mon, 25 Jan 1993 17:59
46 lines
2423 bytes
   From: ctoomey@ccvax.ucd.ie
   Newsgroups: comp.windows.open-look
   Date: 22 Jan 93 13:27:48 GMT
   Organization: University College Dublin

   Hi All,
	   came across a weird problem with XView 3.0 today. I created a canvas as
   a child of a frame and attached 11 items to it's paint window using
   XV_KEY_DATA. This worked fine with XView 2.0 but crashed under version 3.0.
   The cause seemed was an xv_get(window,XV_KEY_DATA,5) instruction which should
   have returned NULL because that item had not yet been set. I tried setting the 
   item in advance - now the thing crashed just after the start of the xv main
   loop. After many hours poring over manuals and wracking my brains for possible 
   causes I tried changing the 5 to a 23. It worked!

	   What I'd like to know is why? Is it a mistake in my code (there are 
   definitely no other items with this number) or is there an instruction in XView
   3.0 like "if key==5 then crash" :-) If anyone has any ideas I'd like to know...


can somebody FAQize this?

anyway, the deal is that the XView library itself uses
XV_KEY_DATA extensively, so you must be certain that the
key you use is unique.  the methodology for doing this is
to obtain the key from the function xv_unique_key(void).

if you just pick arbitrary numbers, especially low numbers,
your likelyhood of collision is quite high, as is your likelyhood
of trampling something that the library depends on.

<<tank

--

*********************************************************************

	Richard M. "Tank" Goldstein		rickg@Eng.Sun.COM
	Window Developer Environment
	SunSoft, Inc.

	"I'm a scientist.  I don't think, I observe."
			-Dr. Clayton Forrester

*********************************************************************
Re: Weird XView 3.0 XV_KEY_DATA problem
#2811
Author: Stan Friesen
Date: Thu, 28 Jan 1993 16:33
14 lines
1061 bytes
In article <RICKG.93Jan25125945@irondude.eng.sun.com>, rickg@eng.sun.com (The Tankster) writes:
|> 
|> anyway, the deal is that the XView library itself uses
|> XV_KEY_DATA extensively, so you must be certain that the
|> key you use is unique.  the methodology for doing this is
|> to obtain the key from the function xv_unique_key(void).
|> 
Another approach, one that I often use, is to use a pointer to some application
datum.  This is extremely unlikely to match any key used internally by the library.

-- 
sarima@teradata.com			(formerly tdatirv!sarima)
  or
Stanley.Friesen@ElSegundoCA.ncr.com
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads