I've posted this yesterday, but it seems to have fallen off the list! So I'll ask again.

Not being the best programmer (understatement) I mean to create a button in various windows to update or rebuild index(es) of the attached tables. I know that I need to create a stored procedure which will have the Update_index at its core, but get hopelessly confused with contract blocks etc. Can someone give me a template script that I can modify with the right details and then attach to a button?

The second question I have is: can you change the colour of the MDI client window *without* switching off the 3D control of the window. Having the 3D control forces (it seems) the system colours (which I on the whole prefer) and this makes the client window a rather boring dark grey.

Joh

Jo,

Fell off the list? I saw it at least. And responded to it too, i.e to the MDI question. Just one thing: Are you implicating you managed to change the colour of the MDI Client Area (or perhaps it's MDI Client Window, as you say, that's the correct name for the rectangle where the child windows appear) when you turned 3D off?

- Oystein -

Sorry Oystein, you're right. I'm going blind and didn't see my own posting. I wonder what causes that?? (It's a rethorical question…)

You're also right in assuming that by turning the 3D control off I can change the colour of the window itself, but not the client area. Anyway, I'll try and see what your solutions look like.

Then there is just the issue of the update_index via a button….

Cheers

Joh

Jo,

Here is what I use in my data entry forms. It's a subroutine that updates all the indexes for a table. I run this subroutine as a quickevent on WRITE. That way the indexes of the form's associated table will always be up-to-date. But it will work equally well in your case - for a user-initiated update on a button CLICK.

Note that the subroutine needs to be told which table to update indexes for. So you must have the table name as a parameter in the quickevent. A more advanced subroutine might find out which table the form is associated with, and not need that parameter. (That more advanced subroutine would need 10-20 lines more coding.)

Note that my subroutine assumes the form has an edit line called STATUSLINE, where it reports progress. If you don't need that feature you can just remove or comment out all lines

UnUsed=Set_Property( @Window : ".STATUSLINE", "TEXT", "...

Also note that there is no error checking in this subroutine. I don't know all the details of Basic+ error checking, but I usually use either @File_Error for "primitive" statements like open, read, write, select etc, or Set_Status/Get_Status for more "high-level" stuff. I'd expect Update_Indexes to fall in the second category, but in my experience Update_Indexes and its ilk fall somewhere in between. I'll append another piece of code and some comments at the end of this posting.

Btw - if you want to rebuild indexes instead of updating them, just change the third parameter of Update_Index from "" (false) to "1" (true).

Here's my indexing update function:

subroutine Update_Indexes( TableName )

	declare function Get_Property
	declare function Set_Property
	
	declare function Utility
	
	declare subroutine Update_Index
	
	/* set hourglass cursor since the indexing process may take some time */
	UtRetVal=Utility( 'CURSOR', 'H' )
	
	UnUsed=Set_Property( @Window : ".STATUSLINE", "TEXT", "Checking to see if the table has any indexes..." )
	
	/* find out which indexes the table has got */
	Indexes=Xlate( "!" : TableName, '*INDEXES', 1, 'X' )
	
	if Indexes then
	
		NumIndexes=count(Indexes, @VM) + (Indexes  "")
		
		OldVal=Set_Property( @Window : ".STATUSLINE", "The table has got " : NumIndexes : " indexes..." )
		
		for I=1 to NumIndexes
			UnUsed=Set_Property( @Window : ".STATUSLINE", "TEXT", "Indexing index no " : I : " - " : Indexes : "..." )
			Update_Index( TableName, Indexes, "" )
		next I
		
		UnUsed=Set_Property( @Window : ".STATUSLINE", "TEXT", "Indexing finished" )
		
	end else
	
		UnUsed=Set_Property( @Window : ".STATUSLINE", "TEXT", "The table has no indexes" )
		
	end
	
	/* normal cursor */
	UtRetVal=UTILITY( 'CURSOR', 'A' )
	
return 0

And here's a piece of code with an Update_Index call and proper (?) error checking. In this example, in case of error, I just return the error code/message. In my experience calling Update_Index with an existing table and non-existing field results in a @File_Error but not error status from Get_Status. But calling Update_Index with non-existing table results in an error status from Get_Status.

	... ... ...
	declare function Get_Status
	declare subroutine Set_Status
	
	declare subroutine Update_Index
	
	TableName=...
	FieldName=...
	Rebuild=...
	
	Set_Status( 0 )   /* it's safest to reset status both before and after */
	Update_Index( TableName, FieldName, Rebuild )
	if Get_Status( StatusCode ) then
		/* failed */
		Set_Status( 0 )   /* it's safest to reset status both before and after */
		return StatusCode 
	end else
		if @File_Error then
			return @File_Error
		end
	end
	
return 0

- Oystein -

Jo,

Crossed my mind you might be satisfied with simpler program code. Instead of the subroutine first finding out which indexes there are, and then run in a loop through all indexes, you can just do a single

Update_Index( TableName, "", "" )

The main advantages with the loop is that you can report progress. Your users will like that if there are very many indexes or a large backlog of unindexed rows. (I have also had a case with a (networked) app where something went wrong during indexing, and it was very useful to know that the hang occurred on one particular index.)

- Oystein -

Fantastic, Oystein! I'm more than a little obliged. Thanks a lot.

Joh

View this thread on the Works forum...