Integrate a browse into a "getfield" of 2nd Browse

[jayadevu]

Regarding OTC's Mediator for MySql, can you please send the url ?
Sudip

the url is http://www.otc.pl/

Regarding your discussion about the tips for "browse", what is the url.


Warm regards,

Jayadev

[sudip]

Please check following urls.

viewtopic.php?f=5&t=313

viewtopic.php?f=5&t=302

viewtopic.php?f=5&t=210

Regards.

Sudip

[swapan]

Jayadev, thanks for initiating this thread. And thanks to all who have supplied their inputs. Please allow me to put my 2 cents here:

CLIPPER+DBF SCENARIO:

In a invoice entry my multiple-entry portion (where all the items inputs are taken in) consists of arrays but the help list calls for routines which are based on dbedit.

Yes, in my clipper applications I used DBEDIT to create Help Lists for Masters (Item, Party, ledger etc.) instead of arrays. User presses F1 in the GET field and the list pops-up. On particular cases the Lists pops-up straight away and during modification mode the lists poups up and the highlighted bar is positioned on that particular data (with respect to that GET) in the list. So in this approach in a multi-user environment there's no need in maintaing the arrays with respect to any modification/addition/deletion in masters from other terminal and the user at the Invoice Entry module always gets the latest uptodate data of the masters. And I have not found any noticeable slowness in fetching the data in this way in a LAN environment.

Something like this (partially produced):

@ l,10 get a_prdcode[mslno] pict '@!' when ProdHlp(a_prdcode[mslno]) valid ProdValid(a_prdcode[mslno])
read

static function ProdHlp(cCode)
save screen to oldscr
save screen to prv_scr
prvcolor := setcolor()
prvarea := select()
set key K_F1 to Prod_help
retu a_prdcode[mslno],.t.

function Prod_Help(cProc,nLine,cVar)
local getlist := {}
set key K_F1 to
.
.
.
PRODMST->(dbedit(11,00,21,79,nfield,"ProdSearch",,acColumns))
set key K_F1 to Prod_Help
retu

VB+MSSQL SCENARIO:

I assume in MSSQL we cannot approach in that DBEDIT/BROWSE way for a table. Here we definitely should use GRID. There are many professional 3rd party grids (like Component One) which helps a lot forVB/.NET platforms. In any case here also we can avoid Arrays and my approach will be like this:

01. On the main form we will need two grids. Multiple/Table entry portion (for taking mutiple items inputs) will be based on Grid and the Help List we be also based on another grid. It takes lot of time and R&D to "tame" a grid for an invoice/voucher entry module if you are looking for the user-friendliness of your Clipper application and full keyboard navigation and mouse operation simultaneously.

02. Fire the SQL SELECT Query for that master table. And fetch that data (recordset) in a Grid and then display the grid as a Help List.
03. The selected item's values gets returned to the concerned cell in the entry grid.
04. I would prefer not to use combo box/list box in the entry grid for the product input, instead would invoke the HelpList grid as mentioned above.
05. In VB/.NET the 3rd party grids can be saved also. So if reqd. for the 2nd time you may not populate the grid and load the same grid with filled data.
06. GRIDS are better as we can hold additional data which may be needed in our program but shouldn't be visible to the user. This can be done by using column hiding property or atleast we can make column width 0.
07. Limitation of grid: nos. of rows it can hold. Well, I assume in our projects it will not be crossing the limits!
08. I once again want to voice that its very tough to "tame" a grid for any Invoice/Voucher Entry module, but once we achieve that, then there's always our that "Copy & Paste" method for next entry module!

SORRY GUYS! I'VE STRETCHED THIS POST TO THIS LENGTH!!

Regards,

Swapan
[ps:BTW Jayadev, your Clipper5.3 approach for Invoice Entry was cool! Never thought like that as always used arrays method from Clipper 5.1."Aap se dosti karna padega!"]