Search options (Page 92 of 104)

Hello Timlitw,
Not sure if I'm missing something (probably - LOL!).  Can't you filter the comboboxes in the same way that you filter the grids (using the vlocation filter in my previous attachment).  That was the thinking behind the approach I took to make it re-usable.
The relevant code (in my attachment) is:
formcalculate.combobox1.dbFilter := 'location = "'+vlocation+'"';
formcalculate.combobox1.dbupdate;
I've added it to this attachment (user passwords are 100, 200, 300, 400 and administrator passwords are tim, derek).
Let me know if I've missed something.
Regards,
Derek.

Hello Gonpublic,
What you've described is certainly possible in MVD.
However, without knowing more about your project, your database design and the process flow, it's difficult to suggest options. 
My initial question is why you need the split across two forms if the additional actions information is to be saved to the same record (or is the additional actions information being stored in a related, one:many table)?
Could you attach a copy of your project?  That would help a lot.
Derek.

Hello Timlitw,
I didn't realise you'd have so many locations.
So, I've altered my original approach to allow for this;  whatever the user location, the script just reads it and filters a common tablegrid accordingly.   The user only sees the data for their location.  As an administrator, you get to see ALL locations and to maintain the reference tables (passwords, locations etc).
Valid administrator passwords are 'derek' and 'tim'  Valid normal user passwords are 'celtic', 'derry', '100' - but you can see them all in the passwords table if you go in as an administrator.
Because there is hardly any data, I also put the location into the caption at the top of the form (as confirmation that it is switching locations correctly, according to the user you've logged in as).
I think this should address the concerns about the possible number of locations that you have.
Derek.

Hi Gonpublic, EHW,
Attached is one approach you could take (there are lots of others - but this keeps it pretty basic).  It uses different tablegrids - one showing all columns and allowing maintenance, the other showing limited columns and display only;  which tablegrid you see is dependant on your level of access (determined by your password).
The current passwords to gain access are 'DEREK' (for full access) and '12345' (for restricted access).  However, if it's the first time the app is run, security is by-passed and takes you straight to a password set-up screen where your first entry must be a password with FULL access;  if you wanted to check this out, simply delete the sqlite.db file and run it as if it was the first time.
Hope it helps,
Derek.

Hello Gonpublic,
Have a look at the attached.  You can either display what you want into fields or, as they are not connected to any DB, you could simply display them as labels.
Derek.

Hi Adam,
1.  As I said in an earlier post, any field, button etc that is contained within a panel is subordinate to the settings of that panel.  So it's just one line to enable or disable a panel AND all the objects within it rather than all the extra lines of code you have by doing it object by object.  I'm not sure why you do it that way.
2.  Is there a reason why you mix the 'enabled' and the 'visible' properties?  Enabled=false means that the user sees the object but can't click into it whereas Visible=false means that the user can click into it but then can't type.  Personally, I think it might be confusing for the user.
3.  I've just quickly modified your project so that you can scroll or click through the grid and display values in the edit fields;  this is achieved by issuing an 'edit' click in the script every time you scroll or click in the grid.  In effect you are permanently in 'edit' mode - the script then repositions you back onto the highlighted grid row to give the effect of scrolling and displaying. 
4.  The actual edit button that is visible on the form is fake!  What it actually does is to enable / disable your panels.
It takes a few minutes to get your head around this approach and there are other ways of achieving the same effect (duplicate forms, for example, which personally I prefer as it uses more of standard MVD).
Derek.

Hi Adam,
I don't know if Dmitry has something specific that he can suggest. 
But 'accordions' aren't really much more than clicking on a label to pop open a panel or another label (or a tablegrid or an image etc etc).
See if the attached gives you any ideas.
Derek.

Hi Adam,
Meant to follow up on your question but have been tied up.
Rather than have lots of SQL statements to retrieve fields that you want to display, you can do most of it as part of standard MVD. 
Basically, in your script, you automate 'clicking' an edit button so as you scroll through your grid, it retrieves as many fields of data as you want without any additional SQL calls.  And because it is pretty much standard MVD, there should be no issues with refreshing and updating.
Have a look at the attached project and it might give you a different approach.
It's something I did a while back but I've changed some of it to be relevant to your question.  I use panels instead of page controls / tab sheets but the principle is identical and there is a mix of data coming from both the main and the related tables.
Although there are a few lines of code in the script, 95% of it is either cosmetic or to safeguard against the user creating duplicate rows (because it's all on one form).
Hope it helps,
Derek.

Hi,
It's the same principle - the only difference is that the incremental search is already being used to retrieve student details (so you need to add another button to search for the courses and action the 'click' in the script instead).
You were also retrieving the course details when the value in the schools grid was changing rather than when the value in the courses grid was changing.
One more thing - you really need to repeat all your sql calls AFTER you've done an 'edit' as well, because the updated details will not show (try editing some data on either a student record or a course record and you'll see that your changes are not showing - it's different from just issuing a 'dbupdate' command).  It's probably quite inefficient and will make the script rather long-winded (well, you know how I love a minimal script - LOL!).
Anyway, I think it's doing what you want now.
Derek.

Hi Stelios,
I'm not sure if I understand 100% (but it's not your english, which is good - it is just my understanding of your problem!).
Is the sample project in the attachment the sort of thing that you are trying to do?
Regards,
Derek.

Hi Timlitw,
If you hold down ALT and SHIFT and then click on any of the elements on the form that you want to move, that should do what you're after.
Derek.

Hello Itzik, Timlitw,
I have only just seen your post so maybe you have a solution already.
I have a user who also wanted the tablegrid to have a filter function like EXCEL. 
What I came up with is the nearest that I could get it.  It's not 100% what the user wanted but it's okay. 
Maybe this approach can give you some ideas (please see attached).
Regards,
Derek.