[RESOLVED] Database Input Form

[kobusjhg]

Good Day,
I am doing Fire Surveys and want to make it easier to do this. Currently I am walking through a building writing everything on paper and when I get home I re-write everything in word.




I am looking for a way to do it now in VB and later re-do it in c# android in order to do it on a tablet whilst walking in the building. I have done the DB in Access and created the Data Source in VB.

Maybe I need a form with the following: -

Area Location Quantity Searchable textbox

The area, Location and quantity I will have to put into the form, but the equipment and sizes need to be searched.
This page could consist of maybe 100 lines. At each location I need to add another line with new equipment.

If one looks at the image, that would be all in one line

Is there a way to do this perhaps?

Thank you in advance

[jmcilhinney]

If you're going to write it in C# for a mobile app, it seems like writing it in C# now would be a better idea. That way, you can just reuse most of the code and only have change the UI.

[kobusjhg]

If you're going to write it in C# for a mobile app, it seems like writing it in C# now would be a better idea. That way, you can just reuse most of the code and only have change the UI.

Thank you jmcilhinney, you are right. My intention was to test it in Windows first and then try the Android.

[PlausiblyDamp]

Thank you jmcilhinney, you are right. My intention was to test it in Windows first and then try the Android.

If you are using recent version of Visual Studio then something like MAUI might be worth investigating. That way you could have a single project that could target both Windows and mobile

[Shaggy Hiker]

If the ultimate goal is mobile, then you want to be thinking about a mobile interface from the start. This problem seems a bit awkward for that purpose, thought that may be simply because I'm making some unwarranted assumptions.

If you are talking about a generic building, then the layout of the building seems like it would be necessary, and that will be awkward. If it was one building (or just a small set), then that would be easier.

The thing about mobile is that the less typing you need to do, the better. The simpler the interface the better, too. Having a cluttered interface with small buttons will be harder to work with than spreading that interface onto several forms/tabs/panels/pages/or whatever you want to call them. Mobile also means that you want to do as little typing as is humanly possible. You talk about a textbox, and possibly a searchable something. Those types of controls work better on desktop than on mobile. Breaking it down into buttons could be better, though if you have 100 items, that might not work so well. Still, if you had 10 categories, each with 10 items, then you could have a panel of buttons that takes you to one of 10 different other panels of buttons.

Because of the interface difference between mobile and desktop (a better mouse and a FAR worse keyboard on mobile), I would say that you should start on mobile if you intend to end up on mobile.

[kobusjhg]

If the ultimate goal is mobile, then you want to be thinking about a mobile interface from the start. This problem seems a bit awkward for that purpose, thought that may be simply because I'm making some unwarranted assumptions.

If you are talking about a generic building, then the layout of the building seems like it would be necessary, and that will be awkward. If it was one building (or just a small set), then that would be easier.

The thing about mobile is that the less typing you need to do, the better. The simpler the interface the better, too. Having a cluttered interface with small buttons will be harder to work with than spreading that interface onto several forms/tabs/panels/pages/or whatever you want to call them. Mobile also means that you want to do as little typing as is humanly possible. You talk about a textbox, and possibly a searchable something. Those types of controls work better on desktop than on mobile. Breaking it down into buttons could be better, though if you have 100 items, that might not work so well. Still, if you had 10 categories, each with 10 items, then you could have a panel of buttons that takes you to one of 10 different other panels of buttons.

Because of the interface difference between mobile and desktop (a better mouse and a FAR worse keyboard on mobile), I would say that you should start on mobile if you intend to end up on mobile.

Ok Thank you guys,
jmcilhinney suggested the same. I am currently using VS2019. I think Xamarin could work, but I will explore MAUI as per PlausiblyDamp's proposal as well.

[jmcilhinney]

I think Xamarin could work, but I will explore MAUI as per PlausiblyDamp's proposal as well.

They are basically the same thing.

https://dotnet.microsoft.com/en-us/apps/xamarin

.NET MAUI is the evolution of Xamarin.Forms and uses the latest technologies for building native apps on Windows, macOS, iOS, and Android, abstracting them into one common framework built on .NET.

I've never used either but I'm guessing that Xamarin targeted .NET Framework and MAUI is now targeting .NET (Core).

[kobusjhg]

They are basically the same thing.

https://dotnet.microsoft.com/en-us/apps/xamarin



I've never used either but I'm guessing that Xamarin targeted .NET Framework and MAUI is now targeting .NET (Core).

Thank You Gents,
I am sorry that sometimes it takes long to respond and say to thank you to everybody helping, but in South Africa we have a thing called loadshedding. this basically means the electricity demand is far greater than supply. We are now on stage 6 which means we are 13.5hrs per day with out electricity. I have a desktop so when we do not have power I can not do anything. Even if I have a laptop the battery would have to be charged.

[kobusjhg]

If the ultimate goal is mobile, then you want to be thinking about a mobile interface from the start. This problem seems a bit awkward for that purpose, thought that may be simply because I'm making some unwarranted assumptions.

If you are talking about a generic building, then the layout of the building seems like it would be necessary, and that will be awkward. If it was one building (or just a small set), then that would be easier.

The thing about mobile is that the less typing you need to do, the better. The simpler the interface the better, too. Having a cluttered interface with small buttons will be harder to work with than spreading that interface onto several forms/tabs/panels/pages/or whatever you want to call them. Mobile also means that you want to do as little typing as is humanly possible. You talk about a textbox, and possibly a searchable something. Those types of controls work better on desktop than on mobile. Breaking it down into buttons could be better, though if you have 100 items, that might not work so well. Still, if you had 10 categories, each with 10 items, then you could have a panel of buttons that takes you to one of 10 different other panels of buttons.

Because of the interface difference between mobile and desktop (a better mouse and a FAR worse keyboard on mobile), I would say that you should start on mobile if you intend to end up on mobile.

You are correct, unfortunately this could be various different buildings, schools, Factories or warehouses.
The data will be different with each entry.
Attachment 188668
The Floor info is pre-programmed in the Database. This should probably be a search with a Textbox or Combo Box
The Area should bring up a keyboard to type
The Location should bring up a keyboard to type
The Fire Equipment is pre-programmed in the Database. This should probably be a search with a Textbox or Combo Box
The Quantity should bring up a keyboard to type
The Size is pre-programmed in the Database. This should probably be a search with a Textbox or Combo Box
Sided is pre-programmed in the Database. This should probably be a search with a Textbox or Combo Box
Framed and Hanging a tick for yes and blank for no.
The info I put in on the Input sheet must be saved somewhere for a report later if the survey is called up from on the smartphone or tablet.