I noticed this behavior as well, and dealt with it with a kind of kludge, but hey... it works and I only have to deal with the authorization once - unless I want to reauthorize.

OK, Fri. and Sat. weren't the best days for coding for me, to many micro emergencies and distractions to think clearly.

Anyway, this morning I rewrote a 3rd sendBroam.py using arguments (ie. the right way) and here is what I am getting with Carsomyr's latest build:

If I use the '-a' argument to run authorization, everything goes as planned until the program asks for bbSocket's response, then the connection times out. Note that the authorization does complete and the bbSocket.rc is written but bbSocket refuses any other communication immediately after the first sendstring.

If no argument is given, so that the sendBroam() method is called, again bbSocket accepts the first sendstring (the bro@m) and the bro@m is relayed to the core correctly. But, again, bbSocket refuses any other communication immediately after the first sendstring and asking for the response string times out.

Edit: Basically what I think is happening is that, in this build, bbSocket accepts sendstrings but won't reply to response messages.

Is this intentional ?

I can't duplicate the authorization failure using your python script, but I had to remove the settimeout's because my python doesn't recognize them. Will get a newer version of Python and test again without removing them.

[EDIT : Got new Python version. I only get a timeout on AUTHORIZATION calls when bbSocket needs to prompt the user and they take longer than 2 seconds to respond, but thats to be expected because that is the timeout specified in the script. bbSocket can't respond until the user does. No timeouts when the program already has its status recorded in the RC file.

The problem with the bro@m sending is more complicated. You are not recieving anything back because you have not been authorised yet. The fact that the bro@m reaches the core at all is an error on my part, because unauthorised programs should not be able to interact with the core at all.

[EDIT]
crowmag: AUTHORIZE needs to be called every time a program connects, this lets bbSocket know what its talking to over that specific connection. Your sendbroam2 script worked on the previous build because I accidentaly let the broams through without authorization. Sendbroam2 doesn't work on this updated build becuase it doesn't authorize each connection.
[end EDIT]

I updated the code to prevent plugins from interacting with the core before authorization (which should never have happended in the first place )

You can now specify in the RC file whether bbSocket should require auhtorization by specifying The default is true. I will consider removing this again once issues have been resolved (unless everyone would prefer that we keep the option.

This should let you test anything else without worrying about authorization.
(If a plugin calls AUTHORIZE when authorization is not required BBSocket always returns AUTHORIZED.)

Other changes are:

Only Delmenu now invalidates a menu reference, no other functions do
Notifications now appear as [BB_RECONFIGURE] rather than @@BB_REONFIGURE
You can call stylePath("NULL") to recieve the current style path. If you use stylePath("Any other string") stylePath will be called with that argument but I don't know what that does.

Will try the sendbroam3 script again when I have an up to date Python.

Having trouble attaching the file, will try to edit this again in a few minutes.
[EDIT: files now attached

stylePath(), bbrcPath(), extensionrcPath, and menurcPath(), all accept a string argument that specifies the path to those files, I wouldn't allow setting those paths as I don't think setting them in this manner replicates programmaticly and could cause weird config issues (user, programmer expecting one result and getting another.)

OK, understood.

With the script below, I have no issues (so far), with sending bro@ms and receiving responses.



I tried stylePath("NULL") and as expected it returned:

"C:\Blackbox\styles\zenful.style"

Which was of coarse my current style.

Then I sent stylePath("fiddle.style") which returned:

"C:\Blackbox\styles\fiddle.style"

I then tried stylePath("NULL") again and it returned:

"C:\Blackbox\styles\fiddle.style"

instead of the current style, which of coarse would not be correct.

Just a note to Python experimenters: using single quotes (') in messages to bbSocket will get you a timeout. Although it is perfectly legal in Python to interchange them - bbSocket no likey. I found this out by accident, as I prefer to use them in my Python scripts and unconsciously typed them in to wrap NULL and thought 'what the... that just worked'. So, be mindful of this fact.

Under xoblite calling stylePath("Path to a style") actually changes the current style in the RC file, and once you reconfigure the displayed style will change as well. Not sure if it checks whether the file you passed exists.

bblean returns the string you sent but doesn't appear to do anything else with it, and returns the current style again once you call stylePath("NULL"), or at least it did for me.

I'm used to C and there only double quotes are valid for strings, single quotes are used for single characters. Will update bbSocket to accept single quotes to wrap strings from the next build.

This version can

bind to any IP on the host machine (configured via RC file)
Be controlled via some bro@ms
Add ReadColor,WriteColor and ReadValue functions

Broams are

See the included Readme for a full list of functionality.
Single quotes are now supported for strings.

The latest release does not work in xoblite. However if I recompile it from source against the xoblite sdk, no problems (a couple compiler errors involving strchr() where I had to explicitly cast to a char* but other than that worked fine.)

No clue as to what's causing this, can post the bbLean/bbApi.h include file and blackbox.lib you are linking against? Also what versions of these files are you using (bblean 1.16 or mods?)

I don't know exactly what is happening between bbSocket and xoblite. I've had bbSocket loaded in xoblite bb3 RC1 for most of the day because I recieved a PM from quilk about this time yesterday about bbsocket not working under xoblite. The only problem I picked up was with GetDesktopInfo() (which I fixed in my code and will included in the next update to bbSocket), but quilk said it doesn't load at all into his current development version, so I'm still looking for a problem.

Which version did you test it under Tres`ni? Will ask quilk for a copy of his version to see if I can't locate the problem in my code then.

I compile it using Dev-C++ (and thus mingw) so I have a libblackbox.a and not a blackbox.lib. I use the bbAPI.h from the base bblean 1.16 source and the library is also compiled from the source using the makefile provided by grishka. I attached both in a zip because ".a" files cannot be posted.

Using the latest development beta of xoblite. I'm getting the same behavoir as qwilk, it just won't load. I'd normally tell qwilk to try running your plugin in debug under xoblite in debug, but that won't work I'm betting given that a recompile was enough to make it work for me and last I checked qwilk is using MSVC++ not Dev-C++. I'm at a loss to be honest..

Yo,

I'm a little short on time atm, but I tried a quick diff on bbSocket.cpp version 0.0.3 (which loads fine under my xoblite beta) and version 0.0.4 (which does not). Given that the plugin fails while loading, the issue must be in beginPlugin or any of the functions it calls. The diff told me that two lines had changed between 0.0.3 and 0.0.4:

- startListen(); had been changed to if (listenOnStart) StartListen();
- InitBroamMap(); had been added

Therefore, I tried setting bbSocket.listenOnStart: false in the .rc, and behold, the plugin loads fine. When I tried to make it start listen using @BBSocket.Listen, however, the plugin crashed the core. In other words, it seems the issue is located somewhere in startListen(). According to the diff, the following line in 0.0.3...

...had been changed to the following in 0.0.4...

Any clues?

----------
EDIT: OK, I think I've found the issue. In your default .rc, you have config line saying... ...and if I comment that line out the plugin works just fine (i.e. it will not enter the first if statement above, just like 0.0.3 used to work). It is possible that xoblite and bbLean differ in terms of what they return for an empty string, I don't know, but I guess you need to add some validation of the bind string before using it in the gethostbyname() call.
----------
EDIT#2: Oh btw, while you're at it, do you think you could add the following case to pluginInfo(), which adds support for xoblite's bro@ms list functionality?
----------

BR//Karl -> qwilk

Thanks for the help, my bughunting skills still need a bit of work. I was validating by checking for nonzero length(which worked under bblean) but I'll add in additional validation of the bind string.

Will also add the broam listing and then upload the new version.

Here is the updated version of bbSocket.

Xoblite specific
The error under xoblite when a bbSocket.bind entry was present in the RC file has been fixed.
The broam listing functionality under xoblite is now supported.

General
The bbSocket.bind entry can now also perform a bit more work. Some examples.



Creates a listening socket on the port specified by bbSocket.port and bound to the interface with the given IP address. You will recieve an error on startup if there is no interface with this IP address on your computer. The plugin will still work if you have defined other listening sockets.

Creates a listening socket bound to this address on port 1001.

Creates a listening socket(either unbound or bound to localhost, depending on the value of bbSocket.localhostonly) on port 1001

You can specify as many bind statements as you want in the RC file and each one will create a listening socket. If no bind statements are present, a socket will be created on the port specified by bbSocket.port (or port 25225 if this is not specified) and with binding dictated by bbSocket.localHostOnly.

Custom broams would be a fancy feature (i.e. have blackbox and apps talk to the program that is connected via the socket)

Could do it with two calls like RegisterBroam and UnregisterBroam or smth

Cheers,
Christ

I was thinking this myself but thought it would take a separate plugin, in other words a plugin that would read an rc file that the user could use to create dummy bro@ms - one per line and the plugin would register them.

Of coarse I have no idea if that's possible or how bro@ms get registered but the main thing is to have the messaging going both ways. That's why I was playing with BBBalloon since you can use it as a kludge for this purpose - except you always get a balloon showing up.