Month: January 2023

Last week, I completed various tasks related to the StockTake Detail view functionality that I had done the week before. Search matches with the highlight, bugs in the edit item section, and other minor issues were effectively resolved.

First, the highlight function must be consistent with the search, such that the item is highlighted anytime the user searches for the thing. If there are many results, the first one must be highlighted. I took the wrong approach to fix it, but Mr. Peter showed me how to solve it by adding a highlight boolean attribute.

Next, I made the search matches, using the up and down arrows to navigate the match result. Even though, after a few attempts, the matcher navigator functions ideally, it still has some issues, particularly when the matches swap list pages. More setStates were required to keep the value of the result and the selected result. And I needed to add a useEffect to change the currentPosts, which is the data presented to the user.

Finally, several minor bugs in the editing part needed to be addressed. The quantity and barcode were both changed at the same time, and if only the quantity changes, the barcode becomes empty. That was solved by adding if statements into the edit handlers. I also fixed the bug of updating the Stock Take List data when an item is updated, by adding an useEffect to set mount true and I also added an useInterval to refresh the data.

Overall, last week’s outcome was good after also revising the data table style to align the components in a better way for the user to be displayed.

For this week, I managed to complete the History View which now queries the API, based on the input, and presents the user with item’s history details.

Begun by defining properties for history tab then updated the data binding in the view, to establish a connection between the UI and the data it displays. Defined Wrapper, to map the queried result according to the relevant properties.

Next, started implementing Commands which are used to handle a user interaction or action. Finally, establishing  connection between UI and the API , through Refit, to make the application work. 

Lastly, made the View more robust by making the API result and item’s barcode appear (automatically), when the View loads. Furthermore, implemented logic to accept different Type in any case, basically making it case insensitive. 

As for this week, the problem of the web application factory running the dependency injection during testing was managed to be solve with the help of Mr. Peter. Now the services registered in the dependency injection will no longer be instantiate twice during testing.

Next, after changing the stock take background service to using channel instead of concurrent dictionary. I ran into some problem where the channel is not being dequeue after an item is being queued to the channel. With some help from Mr.Peter, I’m manage to figured the problem was the instantiation of the channel.

The problem was that I instantiate a new channel in the accept command service class hence the item is never dequeue from the channel. Lastly, I refactor the cancel ongoing accept stock take command so that it will work with the current implementation of the background service. Now, I have make so that the channel can take multiple entries and the user will be able to cancel the ongoing accept stock take that they requested.

This week, I concentrated on the StocktakeLineItems. Functions such as deleting a specific item were also completed successfully, as were the search function and the edit section for each item.

First, I needed to modify the search functionality, as it is designed to take you to the page that contains the item. The search result must also be highlighted, which was a bit difficult to implement, but with Mr. Peter’s assistance and explanation, I was able to complete it. However, I’m still having issues with the highlight because it isn’t resetting.

Next, I added a delete handler function to delete a specific item based on its Id. In addition, I created a Model to adjust an Item’s barcode or quantity. The layout was initially straightforward, with only one text box and two buttons to save the newly inserted data. Following that, I changed the layout to display the item-selected data and moved the delete button into the modal view. That was useful because the model is now similar to the edit section, where you have complete control over editing and deleting an item.

Finally, I wanted to finish the search function with a highlight, but that didn’t go so well. The main issue was that the highlight did not reset, and it occasionally kept highlighting all items and becoming stuck on that. After speaking with my supervisor, he explained another logic to solve the problem, which I will implement the following week.

For this week, I managed to finish up learning the fundamentals of WPF application and Prism framework which is a UI (user interface) framework used to create desktop applications. Furthermore, I designed the View of ItemMovement tab which now accepts the barcode, reference #, movement type and dates to filter item movement search.

One of the most important WPF application concepts is the MVVM model. This is a powerful concept as it allows to separate the program logic to the user interface. Moreover, data binding in WPF allows data to flow between UI elements and data objects on the user interface. Furthermore, the Prism framework implements a set of design patterns that aid in the creation of well-structured and maintainable XAML applications, this makes the WPF application easier to manage.

Lastly, I need to implement the logic for History so the query is successfully carried. I have updated the View to include more fields to enable advanced search options. Currently, I’m still trying to implement the ViewModel and Wrapper.

For this week, I managed to complete the client side of the signalR which will receive the progress of the ongoing accept stock take process. This is done using channel to publish the current accept progress to the client. In order to do this, the server and the client has to be in a group to send and receive the information.

On the server side, the server only has to publish the progress to the proper group. The group name is decided using the guid that is created when the accept command is requested. On the client side, the client on has to join the group using the guid provided to receive the progress.

Lastly, the current problem that I have resolve is to change the background service from using concurrent queue to channel. But when trying to resolve this problem and discussing it with Mr.Peter. I’m require to resolve the problem of the custom web application factory running twice during the testing in order to properly debug the background service.

Begun by adding test cases for the new feature Status. Considered on the Entity Relation Diagram (ERD) for the Payment model of the system, sat with my supervisor to finalize the ERD of payment.

Next, I began with the coding aspect of the Payment model, defined entities Payment (which contains the details of that transaction) and PaymentType (having the various means of payment). Moreover, I defined their relation and researched upon many-to-many relation in Entity Framework as one order can have multiple payments and one payment can comprise multiple orders.

Lastly, I got a new task to create a History Query API and display History details on the UI for users to check on any general history. Completed the Query with successful testing and shifted my focus on the UI part. Went through some courses to understand Windows Presentation Foundation (WPF) which is a UI framework used at Tong Hin.

For this week, I managed to finish up the updating of the progress bar for the UI when they user does the accept command. Furthermore, I also managed to fix the problem of the threading issue when testing the background service. I created another endpoint which will cancel the ongoing accept task if the user wish to cancel it.

The cancel request is POST request which take the guid from the accept command. When the user send the guid, the API will check if the concurrent dictionary with the following guid exist or not. From there, if the dictionary exist, the current accept process will be stopped. Mr. Peter also mentioned to make sure the code doesn’t crash when the cancellation is requested and that the background service will still continue running even an exception is thrown.

Lastly, I need to implement SignalR into the background which would essentially send back the progress of the ongoing accept command instead of having the user request the progress every few seconds. Currently, I still trying to create the client side of the SignalR after creating the server side.

Begun development on the new features including the barcode, ids, remark, and name fields. Upgraded the test cases to ensure that these fields are valid. Moreover, I began work on a new feature, which will include the addition of a selling price, discount, and with tax computation and test cases. introduced logic for calculating the subtotal amount after taxes, then moved on to creating the test case. Encountered a difficulty with relation due to the fact that one tax can have numerous line items.

Next. I fixed The issue in the relationship which was that the code misinterpreted it as a one to one relation. Once fixed, I tested out Create Command (since now, when a Order is created, the total amount is computed. Similarly, calculating logic was added to the Update Command and tested.

Lastly, built Status entity which has a one to many relation with Order and provided relevant fields. The aim of status is to inform the cashier about the progress of the order. Started considering the structure of Payment.

For this week, I’m still focusing on resolving the bug that exist in the UI of the stock take. One of the bug that I managed to resolve is the preview function of the stock take which allow the user to preview the line item without going into the detail page. The main problem of what’s causing is the lack of publisher of the event which resulting in the method that handle loading the data grid with the line item not being called.

Next, I need to create the pagination for the stock take line item which will be in the detail page of the stock take UI. The pagination will be handle in the view model unlike the list page which is handled by the API. Currently, I’m still trying to figure out on how to the pagination for the line item.

Lastly, fixing the background service which created separate during debugging in the testing. After refactoring some of the code, the problem seem to still persist. As of currently, I’m trying to resolve these problem at the moment.