Search options (Page 110 of 114)

Hello EHWagner,

Thanks for the information.  I have tried the suggestions from Mathias and yourself and both work well;  it now gives me a couple of further options when writing new projects.
I don't actually have an objection to dropdown lists being connected to a database per se, simply the number of additional tables and forms you have to create and the time it takes for what is essentially an attribute (as distinct from a proper related record).
What I came up with in the end doesn't have any script at all and works entirely off 1 table and users are able to add new values to the various lists without me getting involved (which is always good news!).
I've attached a small demo based on the project that I first used this approach on - it's easier than trying to explain - but you can see all the 'dropdown lists' in their combo-boxes working on form2! 
If you can think of any improvements, please let me know (for example, I was trying to use this approach in conjunction with 'parent combo-boxes' but couldn't figure out a way that saved any time over doing it in the usual manner).
Derek.

Hi Dmitry,
Understood and thanks for getting back to me.
I've managed to put together a bit of a work-around now that will be fine for most of the things I need to do.
Derek.

Hello Carlo, Thierry, Dmitry,
I did a similar small project a while ago (with the help of some code from Mathias). 
I have changed my project a bit to show elapsed hours as well as days and have attached it for you to have a look at.
I added a few rows of sample data and it still seems to be working but haven't put any error checking in place (for example - is the end date before the start date etc etc) but that wasn't your question.
I hope this helps you,
Derek.

Hi Dmitry, Hi Thierry,
It's nice to be aware of the improvements that are planned but as Thierry says, maybe they could be greyed out (or something like that) until they are ready.  Otherwise users will be messaging you in the forum either saying "how do I do this......" or "this isn't working properly....." when it's simply not been fully implemented yet.
Thanks for the explanation and I look forward to when these two features in particular go live.
Derek.

Hey Dmitry,
That works perfectly now.
Thanks for the help - and for the super fast reply.
Derek.

Good Morning Everyone,
Not sure if anyone knows how to help......
I am trying to use Mathmathou's ' "Merry Christmas" procedure in my script and it keeps coming up with the following error -
"Undeclared Identifier at 25 December 2015".
I have tried replacing merry_christmas.tablegrid1.dbupdate with happy_new_year.tablegrid1.dbupdate but it still doesn't work!
Still, I am sure someone will have a suggestion or be able to help - that is what is great about MVD, Dmitry and the people in the forum!
Best Wishes,
Derek.

Hi Roger, Dmitry, Jean and any one else.
As I understand it,
1.  The standard menu items appear ONCE AND ONCE ONLY in MVD - on the first form that is called by your application.
2.  You can remove the standard menu items with a few lines of script which is attached to the first form of your application;  and because the standard menu items ONLY appear on the first form, there is no need to attach the same few lines of script to any other form.
3.  You can replace the standard menu items with your own menu items by script;  and following the logic from above, the script to replace the standard menu items is only attached to the first form of your application  because this is the ONLY PLACE where it appears.
4.  Dmitry has written a script that allows the replacement menu items to appear on a form OTHER than the first form in your application.  In other words the replacement menu items can now appear on Form1 OR Form2 OR Form3 etc etc.
5.  However, I believe the actual requirement is that the replacement menu items appear on Form1 AND Form2 AND Form3 etc etc.
I have attached a small project just to clarify what I think Roger is trying to achieve, using buttons that look a bit like menu items(!) that switch between forms in any sequence!! 
I have already used this approach in an application where users want to swap between forms and whilst it works, I will be the first to admit that it isn't particularly clever.
If this IS the sort of thing that Roger is after and using the attached project as a template, maybe someone could come up with a better way of achieving this.  Or maybe Dmitry can amend the 'Mainmenu on Form2' script to work across all forms - I had a brief attempt and failed miserably - LOL!
Let's all try and work together on this as I'm sure many of us would find it very useful.
Derek.

Hi EHW,
That all makes perfect sense now.
I actually wrote something not too dissimilar many years ago and the concept of the 'leads' table is bizarre - it's virtually stand-alone with only a very loose relationship to any of the other tables in the database.
In the end, I think I 'cheated' by having just a 'clients' table but one of the rows in the 'clients' table was for a client called 'Leads' and if any of the queries against the 'Leads' client got firmed up, I then created it as a proper client and copied the data over.
It sounds like quite a large project you're undertaking.  Best of luck and keep us updated with how it's going - it looks pretty interesting.
Derek.

Hi Jumper,
Apologies if I've misunderstood your question.
You can't (easily) populate entries directly into a combo-box (like in Excel).  Entries need to be added to a table first like any other data field(s). 
Once created, these entries are then referenced by using a combo-box on the form where the data is required. 
I've attached a knock-up (it's easier to show it than to explain).  I've used 3 different 'styles' for the combo-box entries with 3 discrete 'save' buttons:
1. the 2 digit state code
2. the state description
3. the two concatenated together
Obviously, you wouldn't normally have all 3 on the same form, I've just done it to show you the options you have.
Hope this helps,
Derek

Evening EHWagner, Dmitry,
If you are going to keep changes and deletions in sync between the main tables and the copy tables manually, then most of the complications that I foresaw go away (thank goodness!).
To help keep things in sync, I think I'd perhaps use something like auto-generated 'counters' on the parent and child master tables that would then get copied across to the sub-set parent and child copy tables.   Matching on the 'counters', you could then use a simple tablegrid to highlight any inconsistencies between master and copy records (where one had been changed but the other hadn't, or where the number of child records belonging to a parent record was different between the master and the copy etc etc). 
It's quite unusual to purposely duplicate actual data in a database.  Can I ask what your requirement is to hold a PHYSICAL subset of the parent and child tables rather than just creating a VIRTUAL subset by using something like tablegrid filters?  Then all of the issues of inserts, duplicate data and keeping records in sync would disappear. 
Derek.

Hi TCoton, Hi Matthias,
It is also quite nice not just to set various fields to enabled := false but also to change their colour otherwise the user might be tempted to try and click in fields that are still showing 'white' - I tend to use clbtnface to be consistent with other Windows applications where an option isn't available.
I changed the example I did to show this and it is attached.  Of course, it is a few more lines of code but if it stops errors and makes it easier to use, then it is worth it.
I'm sorry but I'm not sure what you mean when you ask "what is the function check?"
Anyway, hope this helps.
Derek.

Hello EHWagner,

I found your problem far more interesting that what I'm supposed to be doing right now - LOL!  So......a couple of questions.

1.  Will the second parent table ALWAYS be populated (so it can be automatic) or just occasionally (so it would be a manual request)? 
In other words, if the first parent table has 1000 rows, will the second parent table also have 1000 rows or only a subset?
2.  Will this also be true between the first and second child tables?
The reason for the questions is that I can see a scenario where you don't always want the parent record to be copied but when you DO copy a parent record, you would ALWAYS want the child record(s) to be copied.
3.  Is this mainly to avoid having to enter data twice? 

I've mocked up a couple of quick solutions but would just like to know the answers to 1. 2. and 3. above before I see which is most suitable.

More generally, I'm intrigued as to why you need to create the additional parent / child tables in the first place.

Derek.