quote:

Originally posted by exx1976:

quote:

Originally posted by Erick85:
Just saw your (at least I'm assuming it was you) post on Wes Sage's FB page. I remembered at that point you were working on this. Quick question, and it may have been addressed already and I just missed it. I only have an iPhone, so I can't download it yet. Does this only track number of components or is there a function that tracks cost of those components as well?

It does not track cost, no. A handful of people have asked for that, including a couple in this thread as well as one beta tester, but no one yet can tell me how they would want to handle multiple costs for the same item.

quote:

Originally posted by sigcrazy7:

quote:

Originally posted by exx1976:

quote:

Originally posted by Erick85:
Just saw your (at least I'm assuming it was you) post on Wes Sage's FB page. I remembered at that point you were working on this. Quick question, and it may have been addressed already and I just missed it. I only have an iPhone, so I can't download it yet. Does this only track number of components or is there a function that tracks cost of those components as well?

It does not track cost, no. A handful of people have asked for that, including a couple in this thread as well as one beta tester, but no one yet can tell me how they would want to handle multiple costs for the same item.

I wrote a database way back in the 90's that did what you are doing with this app. I was using Paradox 7.

I tracked costs by having the database generate a hidden tracking code for each component, basically a code generated from the item and date. For example, if the bullet was a Hornady 165g interlock that I purchased on 6/1/1995, the code would be 19950601H3040. I typically date my components with a marker, so when those bullets were used, the database would ask for the purchase date and type, so it could find the lot without me having to enter the code. I wouldn't even know the component code, since it was hidden and only used as an index field. When the bullets were purchased, the price was entered, so the cost could be retrieved at the time of loading. The code could also be hashed to generate an average cost for a particular component.

The database would generate cost data when I reloaded, broken down by component used, and also give me costs when I shot them. Btw, the reloads had to have a tracking number, like a lot number, after assembly.

I so wish I still had that database today. I didn't take backups as seriously back in the day.

quote:

Originally posted by exx1976:

quote:

Originally posted by sigcrazy7:

quote:

Originally posted by exx1976:

quote:

Originally posted by Erick85:
Just saw your (at least I'm assuming it was you) post on Wes Sage's FB page. I remembered at that point you were working on this. Quick question, and it may have been addressed already and I just missed it. I only have an iPhone, so I can't download it yet. Does this only track number of components or is there a function that tracks cost of those components as well?

It does not track cost, no. A handful of people have asked for that, including a couple in this thread as well as one beta tester, but no one yet can tell me how they would want to handle multiple costs for the same item.

I wrote a database way back in the 90's that did what you are doing with this app. I was using Paradox 7.

I tracked costs by having the database generate a hidden tracking code for each component, basically a code generated from the item and date. For example, if the bullet was a Hornady 165g interlock that I purchased on 6/1/1995, the code would be 19950601H3040. I typically date my components with a marker, so when those bullets were used, the database would ask for the purchase date and type, so it could find the lot without me having to enter the code. I wouldn't even know the component code, since it was hidden and only used as an index field. When the bullets were purchased, the price was entered, so the cost could be retrieved at the time of loading. The code could also be hashed to generate an average cost for a particular component.

The database would generate cost data when I reloaded, broken down by component used, and also give me costs when I shot them. Btw, the reloads had to have a tracking number, like a lot number, after assembly.

I so wish I still had that database today. I didn't take backups as seriously back in the day.

I see what you're saying, but given that users aren't asked to enter information, but rather pick it from existing information they've already entered, I'm not sure if that workflow would work.

For example, you enter your bullets, and primer, and powder, and brass.

Then, when you define a load, you are presented with dropdown lists for the above 4 components for the load. Then you add powder quantity, OAL, and the quantity of rounds that you loaded. That number of primers, brass, and bullets are then deducted from inventory based on the items you chose, and the math is done on the powder and it is deducted as well.

Brass is differentiated not only by lot number, but also by times fired. Bullets are differentiated by lot number, same with powder and primers.

Assuming, of course, that the user wants to enter all that data. The finer details are not required, since many people don't care about that type of stuff, or the data simply doesn't exist (ie, pistol brass - I couldn't even tell you how many times it's been fired, let alone any lot numbers. Hell, manufacturers are all mixed together even!).

quote:

Originally posted by sigcrazy7:

quote:

Originally posted by exx1976:

quote:

Originally posted by sigcrazy7:

quote:

Originally posted by exx1976:

quote:

Originally posted by Erick85:
Just saw your (at least I'm assuming it was you) post on Wes Sage's FB page. I remembered at that point you were working on this. Quick question, and it may have been addressed already and I just missed it. I only have an iPhone, so I can't download it yet. Does this only track number of components or is there a function that tracks cost of those components as well?

It does not track cost, no. A handful of people have asked for that, including a couple in this thread as well as one beta tester, but no one yet can tell me how they would want to handle multiple costs for the same item.

I wrote a database way back in the 90's that did what you are doing with this app. I was using Paradox 7.

I tracked costs by having the database generate a hidden tracking code for each component, basically a code generated from the item and date. For example, if the bullet was a Hornady 165g interlock that I purchased on 6/1/1995, the code would be 19950601H3040. I typically date my components with a marker, so when those bullets were used, the database would ask for the purchase date and type, so it could find the lot without me having to enter the code. I wouldn't even know the component code, since it was hidden and only used as an index field. When the bullets were purchased, the price was entered, so the cost could be retrieved at the time of loading. The code could also be hashed to generate an average cost for a particular component.

The database would generate cost data when I reloaded, broken down by component used, and also give me costs when I shot them. Btw, the reloads had to have a tracking number, like a lot number, after assembly.

I so wish I still had that database today. I didn't take backups as seriously back in the day.

I see what you're saying, but given that users aren't asked to enter information, but rather pick it from existing information they've already entered, I'm not sure if that workflow would work.

For example, you enter your bullets, and primer, and powder, and brass.

Then, when you define a load, you are presented with dropdown lists for the above 4 components for the load. Then you add powder quantity, OAL, and the quantity of rounds that you loaded. That number of primers, brass, and bullets are then deducted from inventory based on the items you chose, and the math is done on the powder and it is deducted as well.

Brass is differentiated not only by lot number, but also by times fired. Bullets are differentiated by lot number, same with powder and primers.

Assuming, of course, that the user wants to enter all that data. The finer details are not required, since many people don't care about that type of stuff, or the data simply doesn't exist (ie, pistol brass - I couldn't even tell you how many times it's been fired, let alone any lot numbers. Hell, manufacturers are all mixed together even!).

Of course my task was easier. I only had one user, and I knew his exact requirements.

Good luck.

quote:

Originally posted by T-Bohn:
Hey been playing with the app.

Seems good so far.

I am having trouble with the bullet section.

the "save" shows as a bar and covers the pistol rifle option.

I can't move it around or scroll down to choose pistol/rifle

I can't get to them

suggestions?

Thankyou!

quote:

Originally posted by V-Tail:
If / when you do an iOS version, I'll volunteer as a tester.

A thought: Maybe ask around and see if somebody on the forum has a spare iPhone lying around that you could borrow during development. I don't have a spare, but if I did I'd lend it to you.

quote:

Originally posted by Expert308:
I was browsing this thread last week, when another thread popped up about PVI having 8# jugs of Varget in stock. Naturally my first thought was "Umm, how much Varget to I have at home and do I need to buy some more?" And if so, would it still be in stock by the time I found out I needed it? I had to wait until I got home from work to check on it. It would have been a less stressful afternoon if I'd had the inventory right here with me.