Frequently Asked Questions & Research Material

If you have any more specific questions, chuck us an email here.

SalesC crashed randomly when processing a sale, am I okay?

I hope you're okay, as for the program this is an uncommon memory allocation bug thanks to a shoddy line of code in salesbase.c. For the most part I have fixed this bug but earlier releases may be more at risk. Your sale should've processed however so no issues there. EDIT (7/5/16) : After implementing more efficient methods and ways of handling SalesC functionality, I have spent a considerable amount of time looking into how to best allocate the memory for the program. In doing so the random crashes in Sale have decreased significantly.

What did I am to achieve with this project?

By undertaking something like this it was not only a test of my own ability to code but also how I work under pressure and my capability of learning new programming skills under a time frame such as this one. Upon starting this project my knowledge in C was standard but I lacked any experience using GTK+. It did help that I had used things like Microsoft's Windows Presentation Foundation (WPF) as it meant building XML based UI's was made easier but it really shows just how complex (and in some cases limiting) GTK is on first glance. Whilst my friends may have seen it to be a bit stupid I took on such a task, it was worth it as the learning experience and challenge of producing something meaningful (rather than a joke like most of my projects) and whilst the final product may be a bit rough I am genuinely proud of it.

What could you have done better?

Whilst it was a requirement for the most part with SQLite3 (having to initialise the same database for every database related function) and a lot of GTK+ (signal connections and passing parameters can be a bit fiddly if you try to contain them in a function/procedure) my code could've been more modular. This is not to say it's all over the place and spaghetti code in its design, as something like this I believe is inherently complex, but there are a couple of the earlier functions which I look at and think that things could've been made a bit more modular. That being said, I think containing the basic functions required for SalesC in salesbase.c\h and the GUI "helpers" in salesguihelpers.c\h makes up for this in a way. By separating the logical code from the GUI specific code, the whole system is much more structured and easier to dissect. The code in salesbase.c is usable without GTK, in fact the first working prototype for SalesC was a console application whilst I sorted out GTK's dev tools. As for the code in salesguihelpers.c, well that obviously is useless without suitable GUI as set up in mainwindow.c.

Also memory allocation, but that was a learning process which I have slowly fixed with time.

Final Addition

Yeah memory allocation was my biggest gripe, if I would go back and restart this project that would be my number one concern to ensure that it runs as smooth as possible.

What exactly is the flow of SalesC's functionality? I don't want to read the code because it's icky so please can you tell me how it works?

So basically, if you were to start up SalesC for the first time and wanted to add some items, make a sale and then view the sale it would go something like this :

1. Running the application would check the local folder and find there's no salesc.db file. After this discovery, an SQLite database file would be created and the tables within it would be created using the db_create function and the parameter which determines the way product ID's are handled.

2. Adding a new sale in the ideal situation (product ID's are assigned manually) would invoke the new_product_window procedure, actually this is technically a GTK+ event which is assigned to the button in the main menu using a function called g_signal_connect but essentially it's a procedure as nothing is really returned.

3. Something that is noticeable, everything is pointers. The UI elements, the structs in salesbase.c, the parameters in the GTK events; everything is a pointer. This means for the most part, the classic -> is used to access most of the elements of SalesC's custom types. After filling the product fields in the new product window, update_products is called on submit which uses a custom function called new_product. Similar functions exist such as new_sell and new_payment but the basic gist is that these functions return a pointer to their associated type which basically saves the redundancy of having to manually set the variables of these types using the -> syntax. One requirement however is that memory is allocated previously before calling the function, something that is easily done in this instance by calling malloc(sizeof(Product) + 1).

4. After validation has occured, the product is added to the database using theadd_product procedure. Like the new_product function, variants exist for each of the main SalesC types, these procedures taking in a pointer as a parameter, dissecting it and then using the values obtained in an SQL query to INSERT the product into the PRODUCTS database. Oi side note, why are you one of those people who capitalizes their SQL queries? Honestly, I thought it was a requirement but I only found out recently you don't even need to do it so yeah the more you know.

5. Using the sales window, you can make a sale. Products are pulled up by their PLU (product_id in the database context) and then added to a sales_list which is maintained using as SearchSubmitPair GUI helper. Once this sale is submitted, the program checks for the payment type, whether the amount was enough or valid and then adds each one of the products into the sales table as well as a payment into the payment table. A sale item has 3 major things that uniquely identify it. The first is the SALE_GROUP which is basically the ID of the full sale but because each item is added individually there must be something that groups them, this ID that very thing. The second is the PRODUCT_ID which is a foreign key to an existing product, if a discount has been put on the product this is saved in the row as SALE_COST so that future changes to the price don't affect its price. The last is the PAYMENT_ID, like the SALE_GROUP each row is linked to a singular payment which is defined by the amount and the type (possibly the date as well in future releases). Once all these are processed, they are added to the database and the sale will now appear in the sales history window.

6. Clicking "View Sales" in the main menu will bring up a list with previous sales, clicking one of these elements will show a receipt. This receipt is pulled from bringing like elements from the SALES table together (the SALE_GROUP this linking key). The sold price, ID and name is printed in list format, followed by the total cost, total payed, change (if applicable) and GST included. Whilst these receipts can't be printed easily due to limitations of GTK and my knowledge of GTK, it is helpful to have an easily accessible means of keeping tab on sales.

That for the most part is how each main part works in plain terms, there are more functions to explain but the comments in the code are there for that.

Oi mate, that array's not dynamic

I know it's not and I'm sorry :( MAJOR EDIT : The list which holds your items in a sale is now dynamic, oath

Who is your inspiration for creating this project?

Oh I don't know :3 .

What was the inspiration for SalesC?

Using LOTS POS and thinking "surely you could strip this down for a small business".

How do I compile the source code on Windows?

Look into MinGW and possibly Cygwin. Even then the GTK and SQLite3 dependencies are quite the pain.

Could I really use this product as a POS sale system for my business?

Yeah probably, for a large store maybe not but for smaller, single till businesses which do not yet have a POS system, SalesC is perfect. Also it doesn't cost anything, so that's a plus.

Why C?

As a challenge I guess, also eliminates a lot of the clunkiness which comes with other languages.