My SQLGridSelectedView module (SGSV) is a useful tool for displaying data from a database. However there are times you want to place it on a page and NOT have it process!  

Seems strange to place a module on a page then not use it - well it did to me!  But, as Joseph Craig pointed out, there is a specific use case where this is the desired requirement.

Consider a page using some tab module, that has two tabs that each contain single SGSV module.  From the browser point of view both of these SGSV modules exist on the page - the fact that one is hidden behind a tab is strickly an issue with display implementation - and both will be processed by ASP.NET.  What Joe required is the "hidden" module not process as the effort would be wasted as the user would not see the resulting data and the additional processing time hurts the page performance.  The issue becomes complicated when you consider that SGSV does not know it's hidden and must figure it out itself.

So how to you go about ensuring just one occurance of a module type can process without knowing which modules are hidden?  Also, I do not want to rely on a specifics of the certain tab module - this should be a solution within SGSV's control - pardon the pun.

The answer begins when you reverse the problem -- only allow the visible module to process, all others should not process.  So how do we know which module is visible?  It is the module in which the user must select options before displaying a result.  In Joe's requirement, the SGSV module that is visible, requires the user to enter/select some information prior to requiesting the refresh of display.  So, the active module will be the one that the user's work with -- all other are the "hidden" modules.

This still leaves us with issue of how to tell the hidden modules not to process a default request against the database.  This is where Inter-Module Communication (IMC) enters into the solution.  SGSV uses IMC to link several SGSV modules on the same page to selections made in a parent module (see here for an example of IMC linked modules).  So by making each module both a IMC Parent and child module, when a module was used by a user the selected parameters would be send to the other module also located on the page - the hidden modules!!!  This is the solution. 

I revised SGSV to optionally block IMC updates when a IMC Child - meaning if a page refresh is requires via IMC, I will ignore it.  I aslo verified the page refresh was from a button on the page, not just the page post back or initial page load.

So, I am using IMC to stop the processing on modules on a page.  Strange?  But in Joe's case it makes perfect sense.  The modules hidden from view should not be processed.  The page performance is improved, and the solution is solely with the SGSV module.  Sweet!

I am sure there are other methods that could implement the equivalent, however this implementation work well as IMC was already in place.  All that was needed was the addition of a new processing option, and a few well placed IF statements.

Oh, and thanks to Joseph Craig for pointing out this requirement -- this feature will be released in V5.9 of SGSV -- coming soon!

Paul.