List Select (%ls) - How to get the selection

Paul,

The following statement gives me a run-time error

i = clearwin_info@('THIS')

Error:

Runtime error from program:f:\cmasterf95\checkmate\win32\c-master.exe Run-time Error The string THIS is not known to clearwin_info

COORDINATE_PROCESS_ENABLES - in file ccatalog.for at line 1366 [+0055] CATLOG - in file ccatalog.for at line 877 [+83d6] main - in file cmain.for at line 165 [+22ef]

Another alternative to getting the list item selected for a %ls?

John, from Paul's earlier post:

Posted: Thu Mar 07, 2019 2:40 pm Post subject: Reply with quote In the next release of ClearWin+ you will be able to use clearwin_info@('THIS') with %ls.

He is aware of it not working for me (neither installation of 8.50.0).

How about you?

John,

The addition of %ud has made my life (and programming) soooo much easier. That said, it is still a bit 'clumsy' to create a derived TYPE, then populate it with values or pointers to values.

For a %ls,'THIS' in conjunction with %ud: %ud to get the address of an array, then use 'THIS' to get the selection that was just made with the %ls. As an example, with those two elements, I can enable/disable controls that are tied to the array (grey control). And, since these constructs can be used generically, one can create a generic callback to handle multiple %ls instantiations that require similar processing. Saves a LOT of time in programming.

For more complex interactions, I can define a derived type that contains data for (or pointers to) elemental types and pass that along to a control. It's better than using a COMMON for data, since a COMMON ties the interactions to specific variables. %ud gets you to a more data independent way of defining the data for, or interaction with, controls.

The only thing that really gets in the way of true data independence is that pointers to character strings must be specified with the string length. The pointer assignment operator does not give one the ability to define the length at run time, although the internal structure of a character string/array pointer does (as far as I have been able to determine) hold the length (and array bounds) as well as the address of the start of the data.

Bill

Bill

You only get the current 'item selected' when the call back 'reason' is either 'ITEM_SELECTED' or 'ITEM_DOUBLE_CLICKED'. Does this explain the failure?

Paul, no, this did not solve the problem.

The code reads:

	if(clearwin_string@('CALLBACK_REASON') .eq. 'ITEM_SELECTED') then
		selection = clearwin_info@('THIS') ! get the selection
		print*,'This'
	endif

Thanks for looking at this. Bill

Bill

The following sample works OK for me.

program listbox
integer,parameter:: num_items=4
integer cur_item
character*8 items(num_items)
integer,external::cb
common cur_item
data items /'Apples','Pears','Oranges','Bananas'/
cur_item = 1
iw = winio@('%^ls',items,num_items,cur_item,cb)
end program

integer function cb()
include <clearwin.ins>
integer selection
integer cur_item
common cur_item  
if(clearwin_string@('CALLBACK_REASON') == 'ITEM_SELECTED')then
  selection = clearwin_info@('THIS')
  print*, selection, cur_item
endif  
cb = 2
end function

The only thing I can think of is that some 'aberrent' DLL or LIB is getting used rather than the current one.

I have done a complete directory search of all partitions and find none in the Program Files folder that are out of date.

I also searched the registry for entries (i.e. a registered DLL) and can find none either.

Which lib or dll should I have (i.e. a date/size)? I uninstalled all FTN95 and reinstalled per the instructions you provided. Still, does not work.

This might be related, but Plato32 appears to only reference an older help file (i.e. %ud is NOT in it).

Looking at the MAP file from the link step, it only refers (at least at link time) to the Silverfrost folder in the Program files directory.

This might be related, but Plato32 appears to only reference an older help file (i.e. %ud is NOT in it).

Bill,

My understand is if you are accessing Plato as a shortcut from the desktop or task bar, this is a direct link to a tree path, not affected by the PATH definition. If you have multiple copies of FTN95, as I do, you will need to delete the shortcut and re-create. All shortcuts on desktop or taskbar need to be updated. Am I wrong ?

John

Bill

It is quite possible that %ls 'THIS' was added after the v8.50 DLLs were frozen.

Here is a link to a new set of DLLs which hopefully will resolve the problem.

https://www.dropbox.com/s/1s2fohszbz6sjrq/newDLLs37.zip?dl=0

Paul, recompiled and relinked the programs, but still no joy. 'THIS' is still not recognized by clearwin_info@().

John, I have only one version of FTN95 and all related utilities installed. Good thing to look at, though.

Bill

That's strange. What version of the operating system are you using?

Try copying the clearwin64.dll that I built today to the same folder as your exe.

Paul,

I did a full replacement of all the .lib and .dll files, after saving the old ones to a separate folder.

I am running Windows 10 Pro Version: 10.0.17763.

I did a search of my entire system (as a standard user; that's how I have the system set up for development and test), and could find no versions of the DLL's earlier than the 8.50.0 OTHER THAN the 'save' of the older version in a build folder in the development folder to properly build a previous version of my software, and in a delivery folder for my SW (within Program Files) for support of that version (latest release) for my users. In SilverFrost Program Files, it is the proper version.

I hope this is explained clearly enough. If there is something else I can do (i.e. runtime tools that can extract the version of the DLL being loaded), I'm very happy to try that!

Bill

If you...

1. Test using my sample program above

2. Build using FTN95 /64

3. Copy the clearwin64.dll from the above DropBox link and put it in the same folder as the sample exe.

If this fails then it can only be because we are using different versions of Windows 10 (mine is the current Home version).

OK, your sample works using Plato 32 to compile/link/run. So, the version of Windows should not be an issue.

I copied all the DLL's into the executable folder, still fails.

I removed the older versions of the DLL's (uninstalled my older version of the SW). Still failed.

I've looked through the .MAP files from my link and Plato, and can see nothing different re: location of salflibc.lib. I am not an expert on the comparison, but can provide this should it be needed.

Still trying to figure out why Plato works, but my SW does not even with the same DLL's in the executable folder.

Bill

I am confused. Are you saying that your code that uses %ls does not work or that my sample above does not work except when run from Plato?

Paul, sorry for the confusion.

Your code works in Plato or not in Plato. Mine will simply not work.

I am not using Plato to build my code, just a MAKE file to compile and link. Using all standard utilities (FTN95, SLINK, etc.).

My compile template is:

/DUMP /UNLIMITED_ERRORS /PERSIST /no_quit /list $(basename $@).lis /list_insert_files /ignore 242 /ignore 767 /ignore 520 /ignore 21 /ignore 179 /ignore 1031 /ignore 197 /ignore 1225 /ERROR_NUMBERS /persist /SAVE /FPP /CFPP /no_quit /wide_source /implicit_none

The link steps vary, but generally look like this:

$(LINKER) /heap:12000000,6000000 /stack:9600000,4800000 $(DESTINATION)\CMAIN.obj $(DESTINATION)\CFUNC\GUSER.obj $(LIBRARY_CMASTER) $(PROJ4LIB) \((PDFSUPPORT) -file:\)(C_MASTER) -MAP:$(DESTINATION)\C-Master.MAP

I don't specifically call out linking the FTN95 libraries because that was not in the original template I lifted from using Plato in the early days.

The stack/heap values were selected because at some point, the combination of my code and what was being used by FTN95 for window creation (i.e. %lv) was causing a crash. I think this may no longer be necessary, but am unsure.

When I rebuilt Windows 10 Pro to 'fix' the problem with creating a folder via browse_for_folder1(), I built it totally clean, formatting my boot drive before re-installing. I don't know if this is a factor or not for this current issue. It did fix the browse issue completely.

I ran the full compile on the laptop, and my larger code would not work. I ran your sample code there (un-recompiled) and it worked.

I hope this explanation helps. I am happy to try anything!

Just on a whim, I placed your code (via a CALL) before the remainder of my code started. Your code worked, but my code still did not.

My usage is different in that there are other controls defined in the winio@(). My usage is:

	i = winio@('%rjSource or %nl%rjContributor%nl%rjSearch %cb %`^rb[]%ud %`^~28.4ls <== Choose Type%ud%2nl&',
     $		core4(loc(search_response(4))),deselect_sources,loc(search_response(4)),list_selection,4,isel_type,core4(loc(search_response(4))),source_enables,core4(loc(grey_control)))

If it would be useful for me to break this apart, I'm happy to do it.

Found it!!

Using the grave character with %ls, then THIS does not work.

program listbox 
integer,parameter:: num_items=4 
integer cur_item,iw 
character*8 items(num_items) 
integer,external::cb 
common cur_item 
data items /'Apples','Pears','Oranges','Bananas'/ 
cur_item = 1 
iw = winio@('%`^ls%ud',items,num_items,cur_item,cb,loc(iw)) 
end program 

integer function cb() 
include <clearwin.ins> 
integer selection 
integer cur_item 
common cur_item  
if(clearwin_string@('CALLBACK_REASON') == 'ITEM_SELECTED')then 
  selection = clearwin_info@('THIS') 
  print*, selection, cur_item 
endif  
cb = 2 
end function

Bill

I can (probably) fix that and upload a new set of DLLs.