HELP for multi data entry form

[Athletis]

Good evening at all,
I joined this forum because I hope to find a solution to my problem.
I have to manage staff with one or more jobs that match the different salaries. My need is to create a full list of people with the respective qualifications within a single entry screen, where you can go for a number of hours / days that you have worked for each of them. The system automatically calculates the total of each employee.
I thought I could handle this thing with a datarepeater, but I did not succeed in the intent, so for the time being I'm using a very ugly FlexGrid where simulating the end user the ability to write the cells in hours or days.

In attachment you can find an example.

Have any of you already faced this kind of problem?

Excuse me for my poor english!

[SamOscarBrown]

A late welcome to the Forum, Athletis! I see you joined over a year ago, but made your first post today.

Kinda difficult to understand your 'problem' (and FlexGrids need not be 'ugly'...they are great for display of data).

But it seems you have no 'start and end' points (at least start points) for each employee. For example, Ms. Farm, in your example, consulted for 2 days. WHAT 2 days? I am assuming you want this to be updated automatically at the end/start of every day. All of this needs to be recorded in a database of some kind, which keeps track of when someone started a job, and ended a job (and that can be over different sets of days as well),

For example...Jessica Farm was a consultant on 4 October 2017, and again on 31 October 2017 (two days 'so far'). Well, at midnight (say) your program should search the database for all days that Jessica consulted (and performed Secretarial duties, and worked in Public Relations), and then total the costs per job per day. Pretty simple stuff.

But now, the problem is how to get those days each employee worked in those jobs...you should use a separate input form for that, which then can update your database. Now, do you want to do this for a month, a year, a lifetime of each employee?..you need to consider that. Otherwise those totals could be extra large and lose their meaning/intention.

[dilettante]

I didn't see that as a "report" of existing data but as a data entry form.

That would probably require other controls though, like an "employee picker" and a "skill picker" to add the respective rows, where the hours needed would be typed in.

[IkkeEnGij]

i to do interpret it as a data entry thing
what is needed, is some kind of database
with an 'Employee' table and a "qualification' table
and a 1-M relationship between 'Employee' and "qualification'

in your example an employee is nothing more than a container containing some controls
that container is contained in another container that can scroll the employees container
to me that seems perfect for an mdi apllication

here is an example of how it could be implemented

'Form1 is an mdichild with fixed toolwindow border, and controlbox= false
'code in a module

Dim Frm(10) As Form

Sub main()
    Set Frm(0) = New Form1
    Frm(0).Move 0, 0, 0, 0
    For i = 1 To UBound(Frm)
       Set Frm(i) = New Form1
       Frm(i).Caption = "Employee " & i
       Frm(i).Move 0, Frm(i - 1).Top + Frm(i - 1).Height, 7000, 2000  '(int(3 * rnd) + 1) * 1000
       Frm(i).Show
    Next
    Frm(1).SetFocus
End Sub

[Athletis]

Thanks to everyone for the answers. I'll try to explain it better.
This activity must be performed once a month. The user must be able to enter the total number of days for each job. The software will automatically perform all partial calculations and then calculate the total of each diver.
The problem, as IkkeEnGij also said, is related to the fact that the relationship between employee and work is 1-M so my problem is to be able to build something dynamically.
I was seeing the possibility of using PictureBox as a container, but I still have to do specific tests.

[SamOscarBrown]

The answer IS using a database. One to Many relationships are simple to establish. Possibly use an employee table along with a job table, and if desired, a table that keeps track of hours. Relate the three and you have a start. As far as an 'entry form', don't use FlexGrids...simple textboxes are easy to set up and relate to your database.

I'm not seeing a terribly hard problem here.

(PS---yes, I did see that OP wanted a user-data-entry form, but the image shown is not what I might have chosen for that.)

[dilettante]

A database may or may not make sense, but it certainly isn't essential. It might make parts of the full problem easier, but the question seemed to be about user interface design.

I have no idea what some people above are thinking.


This is an odd UI requirement, but with some effort you can create one. I don't know of any existing Microsoft or 3rd party control that provides any kind of "grid" of this kind. The MSHFlexGrid comes the closest, as long as you do a lot of cell appearance tweaking you can get close by using its "hierarchy" capabilities. Of course few programmers seem to be aware of the Data Shaping Service of ADO that you need, much less any idea how to use it.

Or you could invent something from scratch using UserControls. The DataRpeater control comes close in helping but it has one big limitation: the repeated controls must all be the same size (height here).


Here is a demo using text file based data. It could be changed to use a database instead.

It will save any data you create, though the demo doesn't load previously saved data. It also has no "delete" for Skills or Workers, something else you'd want in a real application.





I call the UserControl "Groid" (as in "grid-oid"), and it makes use of a child UserControl "GroidItem." It probably still has bugs but it is just a demo slapped together by editing the heck out of another UserControl I wrote quite a while ago.

Note the *'s in the dropdowns that indicate a Worker or Skill previously added to the Groid. You can't add them a second time. Nearly all of the code is UI management, but that's to be expected.

[IkkeEnGij]

Wow Dilettante, you are the man
i was just preparing an example of using a text file
now that is just peanuts compared to what you did
but since i already did it:
here goes:

a database is ideal,however a simple text file may be enough
an example of such a textfile: (name='1toM.txt')

John Smith
-Designer
-Project manager

Robert White
-sound maker

Jessica Farm
-Consultant
-Secretary
-Public relation

sample code:

Sub main()
    ReDim frm(0) As Form
    Set frm(0) = New Form1
    frm(0).Move 0, 0, 0, 0
    Dim S As String
    Open "F:\1toM\1toM.txt" For Input As #1
        Do While Not EOF(1)
           Line Input #1, S
           If Len(S) Then
              If Left(S, 1) <> "-" Then
                 ReDim Preserve frm(UBound(frm) + 1)
                 Set frm(UBound(frm)) = New Form1
                 Load frm(UBound(frm))
                 frm(UBound(frm)).Move 0, frm(UBound(frm) - 1).Top + frm(UBound(frm) - 1).Height
                 frm(UBound(frm)).Caption = S
                 frm(UBound(frm)).Show
              Else
                 frm(UBound(frm)).Print S
              End If
           End If
        Loop
    Close
    Unload frm(0)
End Sub

[SamOscarBrown]

Hi...guess I am 'some people'.

I have no idea what some people above are thinking.

It just SEEMS that, in addition to doing this 'every month'---

This activity must be performed once a month.

---one might want to keep this information around for awhile. Sure, you can use text files, but to keep a 'record', does it not make more sense to use a more structured DB?

THAT is what I was thinking.

[IkkeEnGij]

+1 to THAT Sam
however a tip of the hat for Dilettante

[Athletis]

Thank you all for the support. Dilettante, however, has created an example that reflects a lot that I need!
All Worker-Skills are already stored in a database, so the two combobox would not be needed because the GROID would be populated automatically.
As you can see in the attached figure, Step 1 performs a query on the database to extrapolate the Workers and Skill list. Values are entered in Step 2 and in Step 3, the total of each worker is calculated.


I've never used Usercontrol, now I'm going to study how they work, because my problem is to easily retrieve all the values entered to store them in the database.

[dilettante]

Well it is just a very rough stab at a solution, relying on some cutting and pasting and band-aids on some old code. it wasn't clear what kind of interaction you need so I just made a lot of guesses.

I'd probably start from scratch creating databound UserControls and hierarchical Recorsdets. Then there wouldn't be so much sloppy fiddling with Id vs. Index values and far fewer properties and methods would be needed.

Something to consider though is that if a "set of information" (a job to be done?) is really large (lots of Workers) you may need to get more sophisticated. A "virtual Groid" that doesn't allocate one GroidItem per Worker would save a lot of resources. Once you get to 100 or so Workers per job that might be worthwhile effort.

And yes, "Groid" is very silly but probably better than just naming them UserControl1 and UserControl2.