Search options (Page 86 of 104)

Hi EHW,
I had a look at this problem but was going for the no-script option as always (only joking!).
It's a neat solution - nice one.
Derek.

Hi Knobby,
If the two tables are linked, the easiest way is to check it against a combobox;  in your example, if it's not in your "parts" table, then it won't be displayed in the combobox.
However, if there are a large number of entries in the combobox, it can be a bit time consuming scrolling up and down for the correct entry.  In this case, there are a couple of options that I could think of.
Option 1 (no script)
With the cursor in the combobox, start typing the part no' and the combobox will highlight all those values that match what you have typed.  This seems the most straightforward way to me but it doesn't allow for wildcards (ie it is a 'left to right' match of what you have entered).
Option 2 (with script - but not much!)
Use an edit field to build a combobox on the fly, depending on what you type into that edit field.  In this example, I'm allowing for wildcard searches so what you type in can appear anywhere in the part no'.
In both options, the combobox is a concatenation of the part no' and the part description (for extra visual validation) but it doesn't affect the searching.
Please see the attached and hopefully it will give you some ideas.
Regards,
Derek.

Hello Mcsimm,
извините, но я не говорю по-русски - но, возможно, вы можете попробовать что-то подобное.
пожалуйста, изучите пример, который я включил.
(Sorry but I don't know much russian but maybe you can try something like this.  Please read the example I have included).
Derek.

Hi Adam,
Not sure why you want to script it?  Seems a lot more straightforward just to use the filter on the combobox object properties (see attached).
Derek.

Hi Manix,
If you show details from two different tables that have a one : many relationship (in your example, suppliers and orderhead) on the same tablegrid, you will always get repeating data.  It's not like a spreadsheet (like Excel) where you can group the data according to a chosen column.
What I'd suggest,if you want to avoid repeating data, is that you use 3 tablegrids (one for suppliers, one for orderheads and one for orderlines) and link the three tablegrids together (please see attached).
I've not had time to test it so if this approach is any use to you, you need to give it a good testing.
Regards,
Derek.

Hi EHW,
Thanks.  As always, I was trying for the zero-script option but had to admit defeat in the end - LOL!
Derek.

Hi Adam, Hi EHW,
After you mentioned in a previous post that everything that comes in on one purchase invoice goes out on one sales invoice (so a strict 1:1) but that there can be a number of adjustments (refunds) against the original purchase invoice, it seemed to me (unless I'm missing something) that from a data design point of view, the simplest thing would have been to hold both purchase and sales information on one single record.  Then you don't have to worry about creating additional records, maintaining links between related sales and purchases, leaving orphaned records, losing traceability  etc etc. 
Simplest is often the best if the design doesn't compromise functionality and I don't believe it does in this case.
Looking back over the history of this topic,  the options have gone from having separate tables for purchase and sales invoices, using the same table but with discrete purchase and sales records and now it seems you can use not only the same table but also the same record!
I haven't attempted to replicate all of the functionality of your existing project but I'm pretty sure that it's possible using the above suggested schema. 
I've knocked up a quick demo to prove some of the more basic functionality - the whole thing can actually work without any script at all (always my target!):  the few lines of script that I've used are only cosmetic, to make it a bit more user friendly.
I appreciate that you and EHW have done a lot of work on this so it's possibly too far down the road to want to change now, but it might yet prove to be of some use.
Regards,
Derek.

Hi Nitin,
I believe the correct syntax is:
      if Scheduling.combobox9.dbitemid = 1 then Scheduling.CheckBox1.Checked := False else Scheduling.CheckBox1.Checked := true;
etc, etc.
Regards,
Derek.

Hi Vasco,
Please see the attached which may give you some ideas.  I wasn't sure if you meant the id in the table or the rowid in the tablegrid so I've shown both, just in case
Regards,
Derek

1.  The 'edit' and 'delete' buttons are hidden when the 'all refunds' button is clicked and redisplayed when the user clicks back in the PI invoices tgrid (see attached screenshot).  Anyway, it's moot as EHW's sqlquery approach tackles the problem more at source rather than simply trying to side-step it and allows editing directly from the 'all refunds' grid which is more functional.
2.  Your design allows for multiple refunds against one invoice, therefore it is quite normal for the PIR refunds tgrid to contain more records than the PI invoices tgrid  - so I am struggling to understand why this is an issue?  And both suggestions (the 'display only' grid approach and the sqlquery approach) behave in the same way and show the correct number of refunds, as far as I can tell.

Hi Adam, EHW,
With regard to your issue with the 'all refunds' button, it stops working once you've viewed or edited a refund (viewing and editing invoices is fine).  To get the 'all refunds button working again, you either have to restart the program OR click on an invoice that doesn't have any associated refunds, so something is not getting cleared properly.
But I'm not sure why you need a 'search' associated with the 'all refunds' button if you're displaying everything.  A 'quick and dirty' way that I could think of was simply to add a hidden grid that is displayed when you click on 'all refunds' and hidden again when you click back in the invoices tables (see attached).  But there's probably a 'proper' way to do it which I'll try and have a look at.
Just a word of caution, but with possibly 3 of us looking at it independently, you need to be careful that we don't end up overwriting each others' changes.
If I get time, I'll have a think about  the other 2 issues you mentioned as well.
Regards,
Derek.