# Example of Passing Window and List References to Another Thread

**URL:** <https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000>\
**Category:** code\
**Tags:** list, threads\
**Created:** [March 14, 2025, 12:42pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000 "2025-03-14T12:42:34Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![donridley](https://clarionhub.com/user_avatar/clarionhub.com/donridley/32/1459_2.png) [@donridley](https://clarionhub.com/u/donridley)\
**Post date:** [March 14, 2025, 12:42pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/1 "2025-03-14T12:42:35Z")

</div>

Special thank you to Mark Goldberg!

I wanted to know how to pass a reference to a LIST control to another thread. I wanted to access the List's properties in the new thread. For example, the maximum number of columns the list has:

`?SomList{PROPLIST:Exists,0}`

With Mark's help I was able to make it work.

In my case I created a global TYPE'd GROUP to ease the passing of parameters to the new thread:

```auto
ThreadGroupType Group,TYPE
WindowRef &Window
ListRef Long
						End

```

Then, on a button's EVENT:Accepted embed:

```auto
ThreadGrp.WindowRef &= Window
ThreadGrp.ListRef = ?List{PROP:FEQ}
Resume(Start(WindowAsParam,,ThreadGrp))

```

I used Resume since I am calling a source procedure.

```auto
The called procedure looks like this:
WindowAsParam PROCEDURE (string pParams) ! Declare Procedure
ThreadGrp LIKE(ThreadGroupType)
WindowWidth Long
MaxCols Long

  CODE
	ThreadGrp = pParams
	WindowWidth = ThreadGrp.WindowRef{PROP:Width}
	MaxCols = ThreadGrp.WindowRef $ ThreadGrp.ListRef{PROPLIST:Exists,0}
	Trace('WindowAsParam')
	Trace('<9>WindowWidth['& WindowWidth &']')
	Trace('<9>ListMaxRows['& MaxCols &']')

```

The output to Debugview++ looks like this:

```auto
WindowAsParam
	WindowWidth[457]
	ListMaxRows[2]

```

---

<div class="post-metadata">

**Author:** ![MarkGoldberg](https://clarionhub.com/user_avatar/clarionhub.com/markgoldberg/32/1511_2.png) [@MarkGoldberg](https://clarionhub.com/u/MarkGoldberg)\
**Post date:** [March 14, 2025, 5:29pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/2 "2025-03-14T17:29:58Z")

</div>

Thank you for mentioning me 😊

Congrats on taking the little information I mentioned about passing the window and FEQ and also the `xWindow $ xFEQ {PROP:Yada}` notation, and using that info to implement what you desired

* * *

I would make some **very minor tweaks** to what you posted:

I’d replace `ThreadGrp.ListRef = ?List{PROP:FEQ}`  
with ` ThreadGrp.ListRef = ?List`

Quite frankly I never saw the point of `PROP:FEQ` as you need it’s value to get it’s value.

* * *

I would replace

```auto
WindowAsParam PROCEDURE (string pParams) ! Declare Procedure
ThreadGrp LIKE(ThreadGroupType)
WindowWidth Long
MaxCols Long

  CODE
	ThreadGrp = pParams

```

with

```auto
WindowAsParam PROCEDURE (string pParams) ! Declare Procedure
ThreadGrp GROUP(ThreadGroupType),OVER(pParams)
                END
WindowWidth Long,AUTO
MaxCols LongAUTO

  CODE

```

Notice how the OVER eliminates the need for the assign `ThreadGrp = pParams`  
Note: both approaches do rely on the correct string being passed, there is no strong typing here to help us.

If you weren’t planning on calling this directly as part of a `START()` (which requires all parameters to be STRINGS), then I would prototype as  
`WindowAsParam PROCEDURE(*Window xWindow, SIGNED xFEQ)`

* * *

This is just a matter of style and convention, but personally I would rename  
`ListRef` to `ListFEQ` or even just FEQ  
where FEQ means **F** ield **EQ** uate , as we see in PROP:FEQ

* * *

I would consider renaming the group to say more about it’s contents  
something like `gtWinFEQ` or `WinFEQGroupType`

---

<div class="post-metadata">

**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\
**Post date:** [March 14, 2025, 8:29pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/3 "2025-03-14T20:29:24Z")

</div>

> [@MarkGoldberg](#):
>
> ```clarion
> WindowAsParam PROCEDURE (string pParams) ! Declare Procedure
> ThreadGrp GROUP(ThreadGroupType),OVER(pParams)
> END
> 
> ```
> 
> Notice how the OVER eliminates the need for the assign `ThreadGrp = pParams`  
> Note: both approaches do rely on the correct string being passed, there is no strong typing here to help us.

Could check  
`IF SIZE(pParams) <> SIZE(ThreadGroupType) THEN STOP('Bug xxxx')`  
to have an idea that the parameter passed is not what was expected.

---

<div class="post-metadata">

**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\
**Post date:** [March 14, 2025, 9:50pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/4 "2025-03-14T21:50:00Z")

</div>

It’s cool that you’re learning new stuff and thinking outside the box, but the accessing of properties of controls across threads seems like it’s approaching the edge of thread instability. Maybe not with the properties you’re currently reading, but if you want to go a whole lot further you might want to try a different path.

This kind of stuff that you’re doing sounds like it could be a good candidate for a class using the Capesoft GUTS interface that can chat back and forth beween objects.

JAT

---

<div class="post-metadata">

**Author:** ![donridley](https://clarionhub.com/user_avatar/clarionhub.com/donridley/32/1459_2.png) [@donridley](https://clarionhub.com/u/donridley)\
**Post date:** [March 14, 2025, 10:43pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/5 "2025-03-14T22:43:00Z")

</div>

I completely understand.

I know of the risks involved with threads and you’re absolutely correct.

However, there’s only 2 or 3 list properties that need and it’s read only.

Yeah, GUTS is pretty cool.

Thank you everyone for your feedback!!!

---

<div class="post-metadata">

**Author:** ![donridley](https://clarionhub.com/user_avatar/clarionhub.com/donridley/32/1459_2.png) [@donridley](https://clarionhub.com/u/donridley)\
**Post date:** [March 17, 2025, 12:06pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/6 "2025-03-17T12:06:20Z")

</div>

![ScreenHunter 117](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/5/5a56de0594ea8fe2724693df7de99597d1365b5c.png)

---

<div class="post-metadata">

**Author:** ![MarkGoldberg](https://clarionhub.com/user_avatar/clarionhub.com/markgoldberg/32/1511_2.png) [@MarkGoldberg](https://clarionhub.com/u/MarkGoldberg)\
**Post date:** [March 17, 2025, 1:05pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/7 "2025-03-17T13:05:48Z")

</div>

![image](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/1/10600c0c9301f31094fd98efb31527a2b75924b6.png)

See Help [Property Access Syntax]

My guess is that It’s most often used for Reports  
as in `Report$?SomeFEQ{PROP:Hide} = TRUE `

---

<div class="post-metadata">

**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\
**Post date:** [March 17, 2025, 1:16pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/8 "2025-03-17T13:16:07Z")

</div>

If you have multiple windows and/or reports open, this is how you specify which one you’re talking about.  
Its use is almost the same as calling SETTARGET before setting/getting properties.

---

<div class="post-metadata">

**Author:** ![MarkGoldberg](https://clarionhub.com/user_avatar/clarionhub.com/markgoldberg/32/1511_2.png) [@MarkGoldberg](https://clarionhub.com/u/MarkGoldberg)\
**Post date:** [March 17, 2025, 1:23pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/9 "2025-03-17T13:23:45Z")

</div>

> [@jslarve](#):
>
> Its use is almost the same as calling SETTARGET before setting/getting properties.

True. FWIW I prefer `Target $ FEQ{PROP:Yada}` over `SETTARGET` because

- there’s no need to save/restore the current target
- you can see the entire meaning in one line, vs. having read surrounding lines for context
  - which has the added benefit of helping when copying code

The amount of typing can vary, it’s less when using one or two property syntaxes, but at some point it becomes more typing

---

<div class="post-metadata">

**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\
**Post date:** [March 17, 2025, 2:47pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/10 "2025-03-17T14:47:41Z")

</div>

Sometimes you gotta use SETTARGET, especially if you use functions that receive FEQ, that don’t also have a WINDOW param.

A caveat to using these target related prefixes though:

You have to be careful with how you name your window/report variables, keeping in mind that a FEQ is simply a field number. Be cognizant of which FEQ belong to which window, or else you could be referring to the incorrect control.

---

<div class="post-metadata">

**Author:** ![CarlBarnes](https://clarionhub.com/user_avatar/clarionhub.com/carlbarnes/32/1859_2.png) [@CarlBarnes](https://clarionhub.com/u/CarlBarnes)\
**Post date:** [March 17, 2025, 3:41pm UTC](https://clarionhub.com/t/example-of-passing-window-and-list-references-to-another-thread/8000/11 "2025-03-17T15:41:52Z")

</div>

> [@MarkGoldberg](#):
>
> there’s no need to save/restore the current target

A way I use to Save and Restore the current Target using the lightly documented `SYSTEM{PROP:Target}`

```clarion
WindowControlENum PROCEDURE(Window W) !Can also take REPORT or APPLICATIOPN
SaveTarget &Window,AUTO !Current Active Target
FEQ LONG,AUTO
   CODE 
    SaveTarget &= SYSTEM{PROP:Target} !Save Current Target
    SETTARGET(W)
    LOOP
       FEQ=0{PROP:NextField,FEQ}
       IF ~Feq THEN BREAK.
       !Debug info on FEQ
    END
    SETTARGET(SaveTarget) !Restore Target
    RETURN

```

This is useful when wanting to work on a Window behind the currently active Window. E.g. you might use PROP:NextField to enumerate all the Controls.

* * *

For Reports in your embed code its ok to `SETTARGET(Report) ; Feq{PROP:xxx}... ; SETTARGET()`. I also tend to limit the scope of SetTarget() to one embed or a small range of lines.

I’m often moving things on the Report and find using PROP:XPos :YPos :Width :Height a bit verbose. I prefer to use GETPOSITION() and SETPOSITION() for 4x smaller code. They cannot use `Report$` syntax so SetTarget() is required. It would be easy to create a Get/Set that passes REPORT so Report $ PROP’s can be used.

IMO its a bad idea to SETTARGET in Template inserted code as you may change a SETTARGET(Report) from the embed code. Another reason to follow Mark’s suggestion to use `Report $ FEQ` syntax. The reason I limit the scope of SetTarget() to one embed.

It’s important to know `SETTARGET()`with no parameter:

> Resets TARGET to the topmost Window in the execution thread with the currently active ACCEPT loop.