commits

date

comment

96133
by Project Collectio...
(4 downloads)
Oct 1, 2012
9:40 PM

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

96132
by Project Collectio...
(0 downloads)
Oct 1, 2012
9:33 PM

Checked in by server upgrade

13513
by jayonas
(27 downloads)
Dec 28, 2007
10:08 AM

Fixed a warning that I introduced when fixing an earlier bug in BLSGE.

13512
by jayonas
(1 download)
Dec 28, 2007
9:24 AM

Fixed a bug in BLSGE that would cause the program to crash when it couldn't connect.

13407
by jayonas
(0 downloads)
Dec 23, 2007
7:49 AM

Created a new DevPlugin project for a developer plugin. This new plugin will contain tools that make developing other plugins easier. The first module in this plugin is LogModule, which allows the user to log the raw traffic data to files. The module appears to be implemented and in working order, though I didn't test it extensively or anything.

In order to make it possible to use the FolderNameEditor for an option's UITypeEditor, I had to change BL to use threads which are set to use the single-thread apartment (STA) model for COM interop. Otherwise the editor didn't work correctly. It wasn't obvious what was wrong with the FolderNameEditor, but the FileNameEditor actually displayed an error message that led me to that solution.

Although the new plugin's project is called DevPlugin, it outputs to Dev.dll because typing '@load Dev' makes more sense than typing '@load DevPlugin'. No sense in every last plugin having the word "Plugin" at the end of its name. The namespace within it is still DevPlugin to avoid naming conflict issues. I also changed SamplePlugin to work the same way (its namespace and plugin-derived class are still called SamplePlugin, but it creates Sample.dll).

13377
by jayonas
(0 downloads)
Dec 21, 2007
2:08 AM

Fixed the bug I caused earlier where BL commands were no longer recognized. It was because the SystemModule expected the @ character to be in a CommandPacket's Command property, but the new SFCommandPacket implementation strips it off, which I think makes more sense.

13275
by jayonas
(0 downloads)
Dec 17, 2007
5:26 AM

Did a whole bunch of refactoring of the hierarchy of Packet classes. It used to be there there was one type of derived packet which was passed contextual information about which protocol was in use. Instead, there is now a derived abstract packet (for example, CommandPacket) from which is derived one or more implementations (SFCommandPacket and GSLCommandPacket). Plugins can work with and filter on the "base" abstract packet and so not have to worry about which protocol is implementing it.

The one minor "gotcha" is that modules still cannot create their own packets in a protocol-agnostic manner. To solve this problem, modules need access to a new function/message like CreatePacket(typeof(CommandPacket)) which returns an SFCommandPacket when using StormFront and a GSLCommandPacket when using the Wizard (or null, if there is no implementation of the packet for the current front end). Not sure of the details yet, but there should be a way to do that.

As a part of the refactoring, I moved some classes into new namespaces. Now, all "base" packets except BLPacket and RawBLPacket live in the BlackLightning.PluginLib.Modules.Packets namespace, and the implementations for all packets of a given protocol are in a namespace underneath that one. BLPacket and RawBLPacket still live in the Modules namespace because they are technically all you need to write a module. The other packets are really just helpers.

I also implemented CommandPacket, SFCommandPacket, SpeechCommandPacket, and SFSpeechCommandPacket, because that's basically what was available under the old system.

Now it should be pretty simple to add new types of packets as needed.

I haven't tested any of this very extensively yet. It would appear that the speech commands and normal commands work okay, but Black Lightning commands are broken. I'll take a look at fixing that next time.

10224
by jayonas
(4 downloads)
Oct 28, 2007
1:48 AM

Merging a bug fix down into the 0.9 release branch. It fixes a startup crash that occurs when the user doesn't have SGE installed.

10221
by jayonas
(0 downloads)
Oct 28, 2007
1:42 AM

5965
by jayonas
(11 downloads)
Sep 5, 2007
1:50 AM

Created a branch for maintenance of release 0.9.

5964
by jayonas
(0 downloads)
Sep 5, 2007
1:48 AM

Initial upload of the mainline.

5963
by jayonas
(0 downloads)
Sep 5, 2007
1:43 AM

Going to reorganize to allow for a better branching structure.

5962
by jayonas
(0 downloads)
Sep 5, 2007
1:13 AM

Initial upload of source code.

5660
by _MCLWEB
(0 downloads)
Sep 2, 2007
7:13 PM

Team project folder $/blacklightning deleted

  • 1-14 of 14 Change Sets
    • Previous
    • 1
    • Next
    • Showing
    • 10
    • 25
    • Change Sets