One Step Forward, Two Steps Back
Since my last update a couple of days ago, where I learnt and overcame thread safe calls, I started to feel like I had progressed with the bot slightly. Now I am able to receive chat from Twitch, I thought it should be nice and simple to add our own chat to the screen and Twitch… Well I was kind of right.
So the first issue I faced, I had the code put together for inputting text and pressing enter to submit the text to chat, the project built successfully with no errors, excellent I thought. Started to test it and it refused to submit the text (see the code below, client.Send() was client.SendMessage(), more on that later), can you see what the issue is? I couldn’t for around 15-20 minutes (with a bit of Google help).
The answer is, there is nothing wrong with the code, it is because I didn’t think to couple it to the KeyUp event, but in the mean time I changed the input box around to couple a submit button as well which really complements the input box well. The moral of that story is to make sure you bind events to functions where needed like below!
Challenge complete, everything is working and it even forced a bit more functionality out for the end user which is awesome! On to the next challenge, so far I have had to dump all my code in one file which looked and felt horrible. I prefer to de-couple my code to make it easier to read, follow the flow etc so this was making my eye twitch a little. The reason I had left it in that state was because when I hastily tried to separate it in the beginning of the project, it didn’t work, I didn’t quite understand why so I decided “screw it, lets get some functionality first” and put it all in the Form’s C# file.
That was the challenge I had set myself this morning, so with a cup of coffee and a bowl of cereal, I started to look into ways to cleanly and easily de-couple the TwitchLib Client and API calls from each other and the form. After a few failed attempt, I utilised my key tool (Google) and got little help that was either easy to comprehend or didn’t require creating a static interface as it felt like it was overkill for what was needed.
After stepping back and watching a bit of Twitch, the thought came to me “the aim is to reference the instance of Form instead of calling a new instance of it”. In OOP, the go to reference for the current instance is using the keyword
this
My next thought was to look at passing said reference to the initialisation of the Api and Client classes which to my amazement worked perfectly fine! Yes, there is a bit of code duplication in the client and api classes but it was working… Except I now started to get an error that the TwitchLib function SendMessage() was now broken for all calls to the client class… Easy fix I thought, lets rename them to Send() and in the client class, make the SendMessage() call there to make life easy and work, which it did!
Now I have spent a large portion of the day to not progress any further but to clean up my code, I decided that is it for the day, next up is working on populating the Viewers list box and Events list box, which we will talk about in the next post!
Pingback: Services can Cause Frustrations – Code Something