Combo boxes in each Browse Row

[dev1]

Hi,

I would like to have a combo box in each row of a browse, NOT one combo which appears on top of a field which the user clicks. The user should then be able to select a value from the combo box and this updates the temp table value.

Is there an easy way to do this in progress ?!! I would have thought you simply define the field in the definitions block as a combo and things should work, however i don't think it's quite as simple as that?

WinNT, 9.1d.
Thanks.

 

[jongpau]

Hi,

I don't think there is a simple way of doing this. You will end up having to do quite a bit of programming to make something like this work (if anybody has done this I would be very interested in hearing how you managed to do it).

I have tried doing something like this a while ago and (on 9.1C) kept stumbling over the fact that Progress does not allow you to query the browse row within a ROW-DISPLAY event of a browse, which made pull out quite a bit of my hair and eventually give up - Progress wins again

You will also have to create all sorts of logic for vertical scrolling, horizontal scrolling (move/resize/hide/view the combo-boxes), resizing of columns etc.

However, if you do make an attempt at it, let me know how you go!

 

[dev1]

Progress Developers,

Is Progress a 4GL or a 2 and a bit GL?

Surely the Progress team could make features like the combo boxes (or any other widget for that matter) appear in the browse widget, MANY other languages do this, and very simply too.

Progress developers should not have to mess about with the x and y coordinates of mouse clicks, handling all sorts of events and results to get a fairly 'simple' thing like this to work. Not to mention the time lost in development!!

Any replies from the Progress Development team welcomed.

(From a very frustrated programmer).

 

[jongpau]

Hello again,

The Browse widget has always been (and still is) a source of frustration for many (and I think including the people at Progress). And yes, it is still way behind in features and functionality. But unfortunately we have to live with it until they (Progress) finally get it right

 

[bendaluz2]

I have achieved this using a third party control (Component One True Dbgrid control) in V8.3, and this allows me to have combo boxes, radio sets, resizable columns, pictures and pretty much anything else I want. Granted, there was quite a lot of work in figuring out how to use it all, but once i'd done all that, I built it into a smart object and now I can just link it into a window, like I would a smart browse.

 

[jongpau]

Hi Bendaluz2,

Interesting, but...
How do you handle large quantities of data to be shown in the control? Wait until it is all there or do you load batches and allow the user to retrieve more if required (through for instance a button)? Just as an example, we have a customer that has over 10000 child records (of one parent) that could potentially have to be shown in a browse...

Also, what I still think is *very* annoying, is that when a frame becomes scrollable and an OCX control is partially scrolled out of view, Progress can't handle it and generates an error In my app I need frame scrolling functionality to be available. Do you have a trick for that as well (if so I would like to hear what it is).

I have achieved this using a third party control (Component One True Dbgrid control) in V8.3, and this allows me to have combo boxes, radio sets, resizable columns, pictures and pretty much anything else I want. Granted, there was quite a lot of work in figuring out how to use it all, but once i'd done all that, I built it into a smart object and now I can just link it into a window, like I would a smart browse. /images/smilies/cool.gif

 

[Mike Carroll]

I think that you've completely missed the point of what the browser widget is for, and what the 4GL really is.

With the current browser, we have a widget that provides automatic data binding to the database. Let me say that again, automatic data binding. There's no such thing in any other language that I know of. As the browse widget can be bound to the database, the number of records that it can display is unlimited.

If each browser cell was constructed from a widget rather than an internal string, this would have a severe impact on the browser performance. The browser can quite easily represent a table consisting of 100,000 records or more, and forcing it to render various different types of widget is a non-starter. I don't believe that PSC will ever try to implement this.

I've been using Java for the last few months, and getting data from the database into a JTable (a Java browser) is an absolute nightmare. There is no automated data binding and there IS a limit to the number of rows that it can display. If I tried to load 100,000 records, it would fall apart at the seams.

You should bear in mind that Progress 4GL is not a multi-purpose language, unlike C, Pascal, Java or most other languages. It is designed specifically for application development and not systems development. e.g. it's a language designed to allow application programmers to develop applications, with the minimum of fuss and without having first to develop any supporting infrastructure.

 

[dev1]

I have come across 4GL's which have browses bound to the database, and moreover, they allow you to specify a number of records to be brought back in a single fetch of data.

So if you had 20,000 records to read in, you specify 1000, the browse would then bring the first 100 records, when the user scrolls to the 100th record, the browse fetches the next 100 records etc.

As for the 4GL being an application development tool, it should allow you to develop applications with minimal of fuss, without using api's or doing clever stuff to get things working, especially when it comes to using widgets.

As i said in the original mail, I don't see what the big problem is when using a browse, if the developer simply specified a certain column as whatever widget, progress displays that widget in the column.

This SHOULD be an integral part of the browse, AND is a part of application development.

Sorry for going on a bit, but i needed a break from dev.

 

[bendaluz2]

In a word, I dont. The structure of the data is such that I never need to have more than about 40 records at a time in the "browse", though the average is probably more like 15-20. I would suggest that this would be a better approach than trying to populate a browse with 10000 records. This is always going to incur an overhead whatever way it is done. I obviously dont know the content or purpose of your data, but I find it hard to believe that this amount of data cannot be broken up into subsets in some fashion, or filters cant be provided for the user, so that they would only be looking at a small subset of data at any time. The way my particular implementation works, is as follows:

row-available runs a query on the data that would be shown in the "browse" and copies it all into a temp table (each record is given a row number and the rowid of the progress record is also stored), it also creates a lock record so that any other user can only view this data read-only. The grid is then initialised, which generates its own trigger events. The trigger events supply a data structure which details the required rows. Another structure is then populated by the rows of the temp table required by the grid. The grid itself manages the calls to this event and by implication which rows are shown in the grid. I just have to pass it back the data it asks for. When a cell is changed, the change is written back to the temp table and an update indicator on the record is set. Then when the external record source is changed or the object is destroyed the updated temp table records are written back to the database and the lock record removed.

There are a few advantages and disadvantages to this particular methodology, which has developed in response to specific user requirements. For example, there is a small delay when changing external record source, as the temp table is created/deleted and changes are written to the database. Also the entire record set is "locked" while the data is displayed. In my particular situation this is acceptable because the delays are small, due to the low record count and the locking is acceptable due to the nature of the application and data. Originally the data was read from and written to the database rather than a temp table, this was introduced purely to increase the speed of grid navigation. If you were to read directly from the database on your 10000 record example, you wouldnt have to manage batches of records, as you supply just what the grid asks for. It manages which records it needs and when. What you would need to do though is have the records numbered in query order, as the grid deals in row numbers

Hope this makes sense, need a beer after explaining all that!

:drink:

Hi Bendaluz2,

Interesting, but...
How do you handle large quantities of data to be shown in the control? Wait until it is all there or do you load batches and allow the user to retrieve more if required (through for instance a button)? Just as an example, we have a customer that has over 10000 child records (of one parent) that could potentially have to be shown in a browse...

Also, what I still think is *very* annoying, is that when a frame becomes scrollable and an OCX control is partially scrolled out of view, Progress can't handle it and generates an error In my app I need frame scrolling functionality to be available. Do you have a trick for that as well (if so I would like to hear what it is).