18 replies to this topic

[Crane]

Title: vBulletin Alert System (vbAS)
Description
The vbAS will run as a desktop alert system in the icon tray. The software will check specified forum RSS feeds and determine if there are any new posts. Upon new posts an alert similar to Microsoft's Outlook email alert will appear in the bottom right hand corner. The user will have the ability to change/add/modify which vBulletin RSS feeds are checked for and possibly in the future any forum RSS feed.

Features I'd like to add:
Transparency (Fade in/out Effects)
Skin/Theme ability
About Form
Preference Form
-- Ability to change forum RSS Feed
-- Enable multiple forums
-- Colors
Alert Sound on new Threads


Features
Loads RSS Feed
Can search forum

Language
Visual Studio C# 2005 Express Edition (can be moved to pro though)

Tested System
Windows XP SP2

Requirements
Microsoft .NET 2.0

Todo
Reconfigure to draw from RSS (currently draws from mysql db)
Port to Linux
Port to Mac

Binary/Executable uploaded. Will post a screenshot once Jordan has uploaded to CC.

Attached Files

•  vbAS.zip   53.91K   44 downloads

[Nightracer]

This is actually a great idea! Once you post your source code I'd like to help in the project do whatever I can although I'm not that great of a programmer. Let me know what you need done.

[WingedPanther]

Porting VS C# to Max/Linux could be a real pain. It may be easier to start in a more neutral language. I know C++ and the Boost library should be able to accomplish something similar.

[brackett]

Mono will run C# on Mac/*nix. The real issue for portability is the GUI toolkit. Mono has a WinForm toolkit, but I don't know how complete it is.

Even using C++, you'd need to use GTK or something similar to have a cross platform GUI.

I'd probably go the route of using an MVP design, starting with WinForm (that is 90% of the desktop) and slapping a native toolkit on it for ports (if Mono didn't run the WinForm properly). Gets you the nice native look on each platform, with a minimal amount of code change. Also would allow a move to WPF in the near future for Windows.

[Crane]

Before I post I need to change some things. If you read my earlier post about the deal gone sour you'd know this was intended for a "Freelance" job for another website. The person wanted it to connect directly to a MySQL DB which I am changing now to read an RSS feed. I'll post the binary here and then I'll post the subversion in google once I figure out how.

Anyone give me a basic tutorial real quick?

EDIT: I'm having issues with the RSS feed. It appears that it doesn't update that often and it only posts new threads.

I plan on putting the Title and Date in a text file and then reading that text file to determine what threads have already been shown. the problem is this will grow to be very large. Anyone have any ideas how I can do this?

RSS Feed: http://forum.codecal...l.php?type=RSS2

[smith]

Just downloaded and tried your software. It runs fine here on my computer. How often does it update? How often does the RSS feed update? To bad it doesn't do posts though, is there anything I can use for that?

[brackett]

There's a lot of Subversion clients out there, but TortoiseSVN is probably the easiest to pick up. It's all driven by Explorer context menus (those ubiquitous right click menus) so it's pretty intuitive.

Before I get into how to use TortoiseSVN though, let's go over the basics.

Subversion uses a copy-modify-merge style of version control, instead of the more traditional lock-modify-unlock style. The good thing about this is that files are never locked - you can always grab them and start working on them. The bad thing is that occassionally, you and another will have modified the same file, and you'll have to merge your changes. Depending on the file, what was changed, and how much communication there is between the 2 folks, merging can be anywhere from painless to a nerve-wracking disaster. Luckily, it's pretty rare for it to be a big deal in practice.

Okay, so here's the basic daily workflow of a Subverison user.
1. "Checkout" the latest copy from Subversion, which makes a copy on your hard drive (called a "working copy").
2. You modify your local copy, making whatever changes you desire.
3. You "update" your working copy, to make sure you have the latest changes. If there are any updates, then you need to retest your local changes to make sure they are still compatible.
4. You "checkin" your changes, and attach a nice note saying what you changed.

Subversion "repositories" (that's what we call the source server) usually have the following structure:
trunk\
branches\
tags\

All main development occurs on the trunk; this is the main line of development and always contains the latest code.
Branches are used to do development away from the trunk. This can be some particularly risky exploratory development (a "spike" in Agile terms), bug fixing a previous release while carrying on development of the next release on the trunk, etc. At some point, branch changes are usually merged back into the trunk - a process that's easier if done as frequent as possible.
Tags are simply snapshot copies with label. This are usually used as release markers. Subversion has no concept of a label, so this is really a copy - meaning you could checkin changes to it. You don't want to do that in most cases though.

Subversion revision numbers are repository wide - not file, or project wide. That means any change to the repository will increment the revision number of all files. In general, revision N and revision N + 1 of a particular file will have no differences.

The Subversion Red Book is the word for all things Subversion. TortoiseSVN also has a good manual, which talks not only of Tortoise but of Subversion.

[brackett]

Quick tutorial on accessing the CodeCall repository using TortoiseSVN....

1. Grab the latest TortoiseSVN (currently 1.3.5 is the latest stable version, but there's an RC for 1.4.0) from here.

2. You can do check outs anonymously, but you'll need a Google Account and be added to the CodeCall project before you can check in (PM me or Jordan with your Google account and we'll add you).

3. If you've been added to the CodeCall project, your username is your Google username, but your Subversion password is a generated one. Check http://code.google.c...osting/settings to get it.

3. To check out - eg., get a copy of the code onto your PC - just right click on an empty folder and click "SVN Checkout". The "URL of repository" depends on whether you're being authenticated or not (the only difference is HTTP versus HTTPS):
anonymous checkouts: http://codecall.goog....com/svn/trunk/
authenticated checkouts: https://codecall.goo....com/svn/trunk/
If you're being authenticated, you'll need to Accept Permanently Google's SSL key, and type in your username and password.

4. Make any modifications needed on your local copy. Make sure it compiles!

5. Right click your working folder, and select "SVN Update". This will update your copy to the latest copy. If there are any changes, please make sure it still compiles and passes tests with your local changes!

6. Right click your working folder, select "SVN Commit". Add any unversioned files needed, and type a nice log message. Click OK and you're done!

[Crane]

Nice looking Jordan. I haven't had the time to do any updates on this project in a while. Perhaps I will find some time this weekend.

[brackett]

I'm thinking of refactoring the RSS code out to a seperate class, and writing some MbUnit tests to support it. From there, we can start adding some of the new features.

I don't want to step on any toes - but I'd like to see some unit tests supporting the logic. For that reason, and also if we're looking to port the logic to a different UI, it'd be wise to decouple the logic from the form. Any complaints?