Jump to content
Developer Wiki and Function Reference Links ×

using data in functions (sub-routines)


Recommended Posts

I am in the throes of attempting to write what is essentially a Custom Selection eyedropper tool. i.e. you click on an object and it will select like objects. I had this tool working well (based off of a script I found on Vector Depot [shamsul Adnan's GDP Suite]

Unfortunately, the way 2008 handles colors, I have no guarantees that an index item will catch all like objects for the four color options(PF, PB, FF, FB). Regardless of the Who, What, Where & Why, here is my question:

It appeared in the documentation that variables that are declared and defined in the main block of code are available to sub-routines. The issue I have, is that it seems that while the variable is available to the sub-routine, the data assigned to it in the main body of code is not available. I really don't think it wise to pass 20 variables of worth of data when performing a ForEachObjectInLayer, way to much overhead. I also do not want to pass a handle to the clicked on object, and retrieve the attributes for each object that FEOIL comes across for the same reason.

Should I pursue looking for ways to make the data available globally, or the other thought I had was to use a criteria selection without any color checking to make a "base selection" set, then use ForEachObjectInList to verify color equality, that way I am reducing passed variables to 12, and only passing data for the objects that meet the other criteria, reducing the overall number of checks. *

=-=-=-=-=- edit=-=-=-=-

I failed to mention, that the code below, is simply proof of concept. Thus in the Functions I am only checking one parameter for the moment, the remainder of checks will be added when I finalize the process.

=-=-=-=-=-=-=-=-=-=-=-

Procedure Selector;
{$DEBUG}
VAR 
x, y						: Real;
OHan						: Handle;
ClassName					: STRING;
lineweight,linestyle,pattern 			: INTEGER;
pfr,pfg,pfb,pbr,pbg,pbb,r,g,b			: INTEGER;
ffr,ffg,ffb,fbr,fbg,fbb,objType			: INTEGER;

Function Selection(h :Handle):BOOLEAN;
VAR
BEGIN
	IF GetLW(h) = lineweight THEN
		SetSelect(h);
END;

Function Deselection(h :Handle):BOOLEAN;
BEGIN
	IF GetLW(h) = lineweight THEN
		SetDSelect(h);
END;

BEGIN 
GetPt(x,y);
OHan:=PickObject(x,y);
if OHan = nil THEN DSelectAll;


if (OHan<>nil) THEN
	BEGIN	
	ClassName:=GetClass(OHan);
	pattern:=GetFPat(OHan);

	lineweight:=GetLW(OHan);
	linestyle:=GetLS(OHan);

	objType := GetType(OHan);

	GetPenFore(OHan,pfr,pfg,pfb);
	GetPenBack(OHan,pbr,pbg,pbb);
	GetFillFore(OHan,ffr,ffg,ffb);
	GetFillBack(OHan,fbr,fbg,fbb);


	IF (SHIFT = FALSE) & (OPTION = FALSE) THEN
		BEGIN
			DSelectAll;
			ForEachObjectInLayer(Selection,1,1,8);
		END;


	IF (SHIFT = TRUE) & (OPTION = FALSE) THEN
		ForEachObjectInLayer(Selection,1,1,8);

	IF (OPTION = TRUE) & (SHIFT = FALSE) THEN
		ForEachObjectInLayer(Deselection,1,1,8);
END;



END;
RUN(Selector);

* As I type that, I am thinking that is a good avenue to pursue regardless. The only issue I see with it, is that I want for people to add or remove to existing selection sets, and I will have to be very careful on how I use the criteria selection....

Edited by ionw
Link to comment

All of the variables that you declare in the VAR statement of the main procedure are global.

If you change them in the main body of the program, they will retain that change for every step afterwards in the execution.

If you change them in a subroutine, they will retain the change for every step afterwards.

I have not looked closely at your code, but it looks to me like you don't have to pass anything other than the handle. Everything else can use the globals to do the comparison.

Pat

Link to comment

Thanks Pat, that is what I assumed too.

However, the when I step through the code using the debugger, it collects the appropriate attributes in the main body, the function call jumps to the appropriate function, but the test for line weight (the only current test in the function) fails.

If I declare a variable within the function to verify that the function is getting the correct line weight, I find that it is, but the equality test still fails.

Well since the documentation and you support the concept, i am going to break it down a little further to see if I can find the problem.

thanks for your input,

ion

Link to comment

I just copied and pasted it in here and it seems to work for line weights.

With no keys down, it selects just the object with the same line weight. With the Shift key down it adds objects with the same line weight to the current selection. With the Option key down it deselects just objects with the same line weight.

There was one compile problem. In the Function Selection, there is a VAR statement with nothing declared after it.

Pat

Link to comment

You know, I am finding the same here. the problem was I was using the Debugger to make sure that everything went to the right place, and the script steps through, but didn't step into the equality test, and nothing happened to the objects.

When I pulled out the Debug call, and started using messages to see what values were being passed around, then it started working. can we say too conservative....

The extraneous VAR statement was when I was assigning the test line weight to a variable so I could see the values of the tested objects in the debugger.

I was on my way back to this post, but you beat me there. Well it appears that I am off and rolling. thanks for the input, and the checking.

ion

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...