Disable Search Window Before Connected

jbyrd · Post by **jbyrd** » 2003-08-21 10:19

I have now seen 4 threads in the Help/Support section go on for 12 or more posts before it was realized that the reason the person isn't receiving any search results is because they aren't connected to a hub!

Would it be possible to "grey out" the search button until the user is actually connected to at least one hub? Or, if they try to open a search window before connecting, they could be told "Must be connected to at least one hub before searching."

I know that this is a complete n00b feature, but I fear that many good shares are being lost due to frustration. It may seem like a no-brainer to us, but dc++ is different than most other p2p clients, and some don't realize that you must be connected to a hub to search for files.

A problem with "greying out" the button is the help forum will be cluttered with "I can't search"...but at least it would be more obvious to those assisting that they aren't connected.

The purpose is not to take load off of those helping new guys in the help forum, but to make it a little easier to use.

Just some thoughts.

TheParanoidOne · Post by **TheParanoidOne** » 2003-08-21 11:25

I like it!

TheParanoidOne · Post by **TheParanoidOne** » 2003-08-21 11:37

[ 792605 ] Disable search while disconnected

jbyrd · Post by **jbyrd** » 2003-08-21 12:59

You da man!

TheParanoidOne · Post by **TheParanoidOne** » 2003-08-21 14:19

I would be, if I actually coded it!

I don't think it would be too difficult (he says!)

jbyrd · Post by **jbyrd** » 2003-08-21 14:32

After laboring over the code in this feature...I'm spent.

TheParanoidOne · Post by **TheParanoidOne** » 2003-08-21 15:05

Bwahaha!!

On a serious note though, in 2 weeks my project will be finished (yay!) and I may try to implement this. Assuming of course, that someone doesn't do it first.

Gratch06 · Post by **Gratch06** » 2003-08-21 16:05

Code: Select all

	//Gratch - Search check.
	//ClientManager.h  line 67
   void search(int aSizeMode, int64_t aSize, int aFileType, const string& aString, bool bMultiSearch = false) {
		Lock l(cs);  
		int countRooms = 0;
		for(Client::Iter i = clients.begin(); i != clients.end(); ++i) {
			if((*i)->isConnected()) {
				countRooms++;
				(*i)->search(aSizeMode, aSize, aFileType, aString, bMultiSearch);
			}
		}
		if (countRooms <= 0) MessageBox( NULL, CSTRING(MUST_BE_IN_ROOM_TO_SEARCH), CSTRING(SEARCH_ERROR), MB_OK | MB_SYSTEMMODAL );
	}

-Gratch06

TheParanoidOne · Post by **TheParanoidOne** » 2003-08-21 17:23

I thought it would be simple.

It doesn't do the icon disabling or anything like that, but it certainly does the job. Excellent!

And it works like a charm.

Sedulus · Post by **Sedulus** » 2003-08-21 19:27

ah, nice going with the patching :)

unfortunately I don't think arne will accept that patch. the UI code just got intertwined with the Client code.
I do think the approach is right though.. a grey search button wouldn't prevent anyone from opening a search window first, closing the hub, and try to search later.
this nice messagebox, like the one that disables connecting to hubs when no nick has been entered, works fine imho.

(so - if I'm right - for it to be accepted, you'd either have to move the check to somewhere in the UI, or fire() something when countRooms <= 0)

jbyrd · Post by **jbyrd** » 2003-08-22 07:48

Progress! Thanks Paranoid, Gratch, and Sedulus!

Code: Select all

if (countRooms <= 0)

What is the "<" for? Murphey's Law?

TheParanoidOne · Post by **TheParanoidOne** » 2003-08-22 14:04

It's always best to take into account all the cases. You never know what might happen.

Gratch06 · Post by **Gratch06** » 2003-08-25 20:34

OK, this being my first time toying with the fire() and onAction system that has been set up, I'm significantly lost.
What I DO know:
I can fire(someobject::Types, <insert other params here>)

It will eventually reach an onAction function which will check the type, and upon finding a match, will execute the appropriate code.

What I DON'T know:
How to link the fire's to the onActions: specifically, which functions do I need to include so that I can fire information from the ClientManger::search function so that it arrives at the correct onAction function? My idea was to put together a DO_MESSAGE_BOX type and let the onAction function take two char* parameters, thus giving the framework for a quick and easy messagebox using any title and text if needed in the future.

-Gratch06

Gratch06 · Post by **Gratch06** » 2003-08-26 21:17

Well, I suppose I should probably put in the code that I had tweaked with that didn't work correctly, so here goes....

Code: Select all

ClientManagerListener.h
enum Types {
	USER_UPDATED,
	INCOMING_SEARCH,
	DO_MESSAGE_BOX //Gratch edit
};

virtual void onAction(Types, const char*, const char*) throw() { }; //Gratch edit

Code: Select all

ClientManager.h

if (countRooms <= 0) fire(ClientManagerListener::DO_MESSAGE_BOX, CSTRING(MUST_BE_IN_ROOM_TO_SEARCH), CSTRING(SEARCH_ERROR) ); //Gratch edit

Private:
virtual void onAction(ClientManagerListener::Types, const char* message, const char* title); //Gratch edit

Code: Select all

ClientManager.cpp
//Gratch edit
void ClientManager::onAction(ClientManagerListener::Types, const char* message, const char* title) throw() {
	MessageBox( NULL, message, title, MB_OK | MB_SYSTEMMODAL );
}

Hope this helps to find the mistake I've made!
-Gratch06

Post by **GargoyleMT** » 2003-08-31 09:25

Isn't a nice, clean way to do this to detect an offline condition in the search frame, and disable the Search button?

Disabling the Search icon is on my todo list, after all, I do have disabled-state bitmaps for the toolbar in my mod... I just need to contribute a patch to Arne.

cyberal · Post by **cyberal** » 2003-08-31 18:53

I think disabling the search button itself could create new questions in the forum about why the search button is broken, I think the best would be to diable the searching inside the search window and to put a msg where the search results should go... "You need to connect to at least one hub to search!"..

Gratch06 · Post by **Gratch06** » 2003-09-01 08:09

Sedulus wrote: do think the approach is right though.. a grey search button wouldn't prevent anyone from opening a search window first, closing the hub, and try to search later.
this nice messagebox, like the one that disables connecting to hubs when no nick has been entered, works fine imho.

cyberal · Post by **cyberal** » 2003-09-01 11:49

still disabling the search icon is on Gargoyles todo-list, this I don't like!

Post by **GargoyleMT** » 2003-09-02 10:49

cyberal wrote:still disabling the search icon is on Gargoyle's todo-list, this I don't like!

Tough noogies.

There are a million ways to solve this problem, and disabling the search menu item, keyboard shortcut, and toolbar icon is a pretty good one. Especially if you add an "OFFLINE" or "ONLINE: x/y/z HUBS" to the status bar.

I can suggest other solutions, if you're up to coding them. Are you?

Gratch06 · Post by **Gratch06** » 2003-09-14 19:13

Code: Select all

//ClientManager, public portion of class
   int getNumberOfOnlineClients() { //Gratch added for Search window
		int counterVar = 0;
		for(Client::Iter i = clients.begin(); i != clients.end(); ++i) {
			Client* c = *i;
			if (c->isConnected())
				counterVar++;
		}
		return counterVar;
   }

Code: Select all

void SearchFrame::onEnter() {
	//Start Gratch add search window
	if ((ClientManager::getInstance())->getNumberOfOnlineClients() == 0) {
		MessageBox( CSTRING(MUST_BE_IN_HUB_TO_SEARCH), CSTRING(SEARCH_ERROR), MB_OK );
		return;
	}
	//end Gratch added search window
   ...

This fixes the bug with the UI being separate, as well as a bug with autosearch for alternates. This way, it only appears after you've clicked the search button and not just anytime a search is done. It also makes it stay on top, instead of just floating wherever it pleases.

-Gratch06

[Edit: TPO: Class name modified as requested ]

Twink · Post by **Twink** » 2003-09-18 23:53

I'm just guessing here, but isn't that first part of code meant to go in ClientManager not Hubmanager (since the second one u get the clientmanager object and call the function with that?)

Gratch06 · Post by **Gratch06** » 2003-09-19 10:18

Twink wrote:isn't that first part of code meant to go in ClientManager not Hubmanager

Ya....you're right. That was just a typo..sorry

-Gratch06

(If a mod would like, they can correct it, I wouldn't mind

)