Insane Objects - Revision history

Mefistotelis: lv internals ref fix

2020-06-15T16:25:39Z

lv internals ref fix

← Older revision		Revision as of 16:25, 15 June 2020
Line 23:		Line 23:
	* 4C -- this is a hexadecimal number indicating which object.		* 4C -- this is a hexadecimal number indicating which object.
	* name.vi -- which [[VI]] had the insanity		* name.vi -- which [[VI]] had the insanity
	* {dsitem} 0x400 -- really only meaningful if you know how [[LabVIEW internals]] work; in this example it is [[Data Space]] item identification		* {dsitem} 0x400 -- really only meaningful if you know how [[:Category:LabVIEW_internals\|LabVIEW internals]] work; in this example it is [[Data Space]] item identification
	* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for [[DDO\|Data Display Object]] (the last D is because it has to be 4 chars).		* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for [[DDO\|Data Display Object]] (the last D is because it has to be 4 chars).

Mefistotelis: more refs

2020-06-15T16:17:47Z

more refs

← Older revision		Revision as of 16:17, 15 June 2020
Line 23:		Line 23:
	* 4C -- this is a hexadecimal number indicating which object.		* 4C -- this is a hexadecimal number indicating which object.
	* name.vi -- which [[VI]] had the insanity		* name.vi -- which [[VI]] had the insanity
	* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; ~~I'll skip~~ it ~~here~~		* {dsitem} 0x400 -- really only meaningful if you know how [[LabVIEW internals]] work; in this example it is [[Data Space]] item identification
	* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars)~~. A DDO is either a control or an indicator~~.		* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for [[DDO\|Data Display Object]] (the last D is because it has to be 4 chars).

	Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.		Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

Logmanoriginal: Add See also

2020-06-11T09:16:21Z

Add See also

← Older revision		Revision as of 09:16, 11 June 2020
Line 42:		Line 42:

	'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.		'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.

			== See also ==
			* [[Heap Peek]]

	[[Category:LabVIEW internals]]		[[Category:LabVIEW internals]]
	[[Category:Development Environment]]		[[Category:Development Environment]]

Mefistotelis: /* The displayed message */

2020-06-10T23:22:40Z

The displayed message

← Older revision		Revision as of 23:22, 10 June 2020
Line 16:		Line 16:

	An example of the insanity message may be:		An example of the insanity message may be:

	'''''Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)'''''		'''''Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)'''''

	The cryptic nature of the message can be deciphered as follows:		The cryptic nature of the message can be deciphered as follows:
	* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"		* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"

Mefistotelis: style

2020-06-10T23:22:25Z

style

← Older revision		Revision as of 23:22, 10 June 2020
Line 11:		Line 11:
	If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.		If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.

	The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[~~front panel~~]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.		The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[Front Panel]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

	== The displayed message ==		== The displayed message ==

			An example of the insanity message may be:
			'''''Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)'''''
	The cryptic nature of the message can be deciphered as follows:		The cryptic nature of the message can be deciphered as follows:
	~~Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)~~
	* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"		* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
	* 4C -- this is a hexadecimal number indicating which object.		* 4C -- this is a hexadecimal number indicating which object.
	* name.vi -- which VI had the insanity		* name.vi -- which [[VI]] had the insanity
	* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here		* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here
	* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.		* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.
Line 27:		Line 28:
	== Using Heap Peek ==		== Using Heap Peek ==

	There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the ~~culpit~~.		There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the culprit.

	After you have the number, [[Heap_Peek#Enabling_Heap_Peek\|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).		After you have the number, [[Heap_Peek#Enabling_Heap_Peek\|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).

Mefistotelis: explanation at top, better structure

2020-06-10T23:15:14Z

explanation at top, better structure

← Older revision		Revision as of 23:15, 10 June 2020
Line 1:		Line 1:
	~~Firstly, there is no need to necessarily report generically to~~ [[NI]] that ~~LabVIEW has insane objects, as they '''do''' know about insane~~ objects. ~~Secondly they are NOT merely bugs: insane objects can be generated as part of~~ the ~~LabVIEW~~ verification ~~process. If you get such a message~~, it is ~~good to check the known bugs of LabVIEW at ni.com and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support~~.		All objects within [[LabVIEW]], have a self-verification mechanism, which makes each object able to audit whether its internal state is within expected bounds set by LV developers. On specific operations, LabVIEW triggers that sanity check on objects. If any object fails the verification, it is marked as Insane.

	~~The insane object message is what LabVIEW puts in~~ a ~~dialog when one of the objects on the diagram does not meet its "checksum". In other words, this~~ object ~~isn~~'~~t in a~~ state ~~LabVIEW expects it~~ to ~~be in. Most of~~ the ~~time these errors are not fatal~~ -~~- LabVIEW simply puts~~ the object ~~in the state it does expect~~. ~~But it raises questions about how the object got into that bad state and what~~ might ~~have been done with that~~ object ~~between the last time LabVIEW checked~~ and it was ~~good and~~ the ~~time it became insane~~.		For example, if a connection-related object has ''state'' set to connected, but the underlying connection reference is ''NULL'' - the object will fail its sanity test. Another example might be an object which flags suggest it is compiled properly and there was no ''source code'' change which would require re-compilation, but the related machine code references objects which were removed.

	The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the front panel itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.		The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its consistency test. In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

			== Reporting bugs ==

			There is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects; it is a mechanism which developers intentionally introduced. These are NOT merely bugs: insane objects can be generated as part of the LabVIEW internal verification process.

			If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.

			The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[front panel]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

			== The displayed message ==

	The cryptic nature of the message can be deciphered as follows:		The cryptic nature of the message can be deciphered as follows:
Line 28:		Line 38:
	* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.		* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

	'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007~~. A previous author said that few developers really know the capacities of heap peek. This is true... it's a debugging tool, and it gets hacked up to debug whatever anyone needs to debug~~.		'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.

	[[Category:LabVIEW internals]]		[[Category:LabVIEW internals]]
	[[Category:Development Environment]]		[[Category:Development Environment]]

Mefistotelis: /* Using Heap Peek */

2020-05-31T11:39:59Z

Using Heap Peek

← Older revision		Revision as of 11:39, 31 May 2020
Line 17:		Line 17:
	== Using Heap Peek ==		== Using Heap Peek ==

	~~The number "4C" is described above as the number that tells you which object. Not exactly helpful to an end user.~~ There is a way to find and delete an insane object. When you get an insane error, you will get a code that ~~shows~~ the object that is insane - write down that code ~~and then:~~		There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the culpit.

	* Close LabVIEW		After you have the number, [[Heap_Peek#Enabling_Heap_Peek\|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).
	* Put the ~~key "LVdebugKeys=True" in your [[LabVIEW configuration file]]~~
	* Open your VI		The window is divided into several sections. The functionality of the various parts is obscure and mystical; you can read more about it on the [[Heap Peek\|Heap Peek page]]. We're just going to focus on the bits that help with finding and deleting insane objects.
	* Press CTRL+SHIFT+D+H. On Mac, ~~use the command key instead of CTRL. This will open a window known to LV R&D as "~~[[Heap Peek]]~~" since it gives internal views into~~ the ~~front panel heap and the block diagram heap~~.
	* The window is divided into 4 sections~~: top-left, top-right, middle, and base~~. The functionality of the various parts is obscure and mystical~~, so we~~'re just going to focus on the bits that help with finding and deleting insane objects.		* Check the error message given about the insane object. It includes either the letters ''BDHP'' or ''FPHP''. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
	* Check the error message given about the insane object. It includes either the letters BDHP or FPHP. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
	* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.		* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
	* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.		* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.

Mefistotelis: Links to "Heap Peek" page. Probably some info should be removed from here and only be on Heap Peek page..

2020-05-30T17:10:53Z

Links to "Heap Peek" page. Probably some info should be removed from here and only be on Heap Peek page..

← Older revision		Revision as of 17:10, 30 May 2020
Line 22:		Line 22:
	* Put the key "LVdebugKeys=True" in your [[LabVIEW configuration file]]		* Put the key "LVdebugKeys=True" in your [[LabVIEW configuration file]]
	* Open your VI		* Open your VI
	* Press CTRL+SHIFT+D+H. On Mac, use the command key instead of CTRL. This will open a window known to LV R&D as "~~heap peek~~" since it gives internal views into the front panel heap and the block diagram heap.		* Press CTRL+SHIFT+D+H. On Mac, use the command key instead of CTRL. This will open a window known to LV R&D as "[[Heap Peek]]" since it gives internal views into the front panel heap and the block diagram heap.
	* The window is divided into 4 sections: top-left, top-right, middle, and base. The functionality of the various parts is obscure and mystical, so we're just going to focus on the bits that help with finding and deleting insane objects.		* The window is divided into 4 sections: top-left, top-right, middle, and base. The functionality of the various parts is obscure and mystical, so we're just going to focus on the bits that help with finding and deleting insane objects.
	* Check the error message given about the insane object. It includes either the letters BDHP or FPHP. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.		* Check the error message given about the insane object. It includes either the letters BDHP or FPHP. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
Line 29:		Line 29:
	* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.		* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

	'''Note:''' Heap ~~peek~~ does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007. A previous author said that few developers really know the capacities of heap peek. This is true... it's a debugging tool, and it gets hacked up to debug whatever anyone needs to debug.		'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007. A previous author said that few developers really know the capacities of heap peek. This is true... it's a debugging tool, and it gets hacked up to debug whatever anyone needs to debug.

	[[Category:LabVIEW internals]]		[[Category:LabVIEW internals]]
	[[Category:Development Environment]]		[[Category:Development Environment]]

Logmanoriginal: Fix category assignment

2020-04-10T10:01:13Z

Fix category assignment

← Older revision		Revision as of 10:01, 10 April 2020
Line 31:		Line 31:
	'''Note:''' Heap peek does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007. A previous author said that few developers really know the capacities of heap peek. This is true... it's a debugging tool, and it gets hacked up to debug whatever anyone needs to debug.		'''Note:''' Heap peek does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007. A previous author said that few developers really know the capacities of heap peek. This is true... it's a debugging tool, and it gets hacked up to debug whatever anyone needs to debug.

	[[~~category~~:LabVIEW internals]]		[[Category:LabVIEW internals]]
	[[~~category~~:~~development environment~~]]		[[Category:Development Environment]]

Smercer: Change text about editing capacities of heap peek

2007-11-12T14:16:14Z

Change text about editing capacities of heap peek

← Older revision		Revision as of 14:16, 12 November 2007
Line 29:		Line 29:
	* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.		* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

	Note: ~~Care must be taken with heap~~ peek. It has the possibility to change states of objects and doing that without knowing EXACTLY (and I think only a few people in the LabVIEW developer team really do) what you are doing can completely mess up your VI or maybe even more.		'''Note:''' Heap peek does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007. A previous author said that few developers really know the capacities of heap peek. This is true... it's a debugging tool, and it gets hacked up to debug whatever anyone needs to debug.

	~~I do~~ not ~~think that heap peek has~~ any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, ~~I do not know~~ of ~~any edits~~. ~~They may exist. The~~ previous author ~~is quite correct in saying~~ that few developers really know the capacities of heap peek. It's a debugging tool, and it gets hacked up to ~~display~~ whatever anyone needs to ~~display~~.

	[[category:LabVIEW internals]]		[[category:LabVIEW internals]]
	[[category:development environment]]		[[category:development environment]]