Stoic Joker, does whatever you use to call the window open it asynchronously on its own thread, inside of your process? E.g. does your message loop actually matter and do stuff, or could you have used a Sleep(10000) and still have stuff basically function till the loop runs out and kills the app after 10s? In that case I might have a solution as I already bumped into such a problem once in the past.

I tried replacing the whole shebang with Sleep(2000) last night assuming that it just needed some "Hang-Time" to finish getting the Network Connections window open. The window opened for 2 seconds, and then closed.

...So I'm guessing it's somehow important. However it's apparently not important enough to talk to afterwards... as any message I've tried checking for (like WM_QUIT) never comes.

At this point, I'm just waiting for SB to see if there is any type of GUI (tray icon etc.) he wants this wrapped in. Then I could just chain the loop to that and be done with it.

But I do appreciate (and am open for) the suggestion.

Cool, thanks ... I'll take a stab at it (and a few other ideas I came up with) tonight when I get home.

I just noticed from SB's screen shot (in the other thread) that hard-coding the window name ain't gonna work (not that I really had my hopes up...) as it'll close on him in 2 seconds because it can't find a "Wireless Network Connection" window, as his ends in " 2".

Stoic, i tried your file, but it didn't work.  it gives the error "No GUID Given".

Right, you have to give it the machine specific GUID for your wireless NIC.

I have it setup to pass the GUID to the program via the command line
i.e. WiFi.exe 261AAE34-9C9D-40EB-A25C-CFEDF328E3CF

That is why skwire didn't want to get into this because he didn't want to deal with supporting the machine specific hard-coded GUID. Which (is why I cheated) I don't blame him for, as it's a pita. I figured I could get away with feeding the machine specific part to the prog via the command line.

At this point, I'm just waiting for SB to see if there is any type of GUI (tray icon etc.) he wants this wrapped in. Then I could just chain the loop to that and be done with it.

It doesn't need a GUI at all.  It should just be a shortcut icon that you can double click and it will open the window.  It's basically a launcher for the window.  That way, I can take the file and put it in my launcher or start menu or whatever.  It's just a file.[/quote]

True(ish) ... The GUID can (has to) be added to the launch string, but it still has to be dredged out of the registry at some point. I can add a (first run) UI that lets the user pick their NIC from a drop down list and then saves it to an .ini (or in the registry [your choice]). Or we can stick with the (current) command line only option, but I think the UI would be nicer.

It's up to you, let me know.

It's the spirit of the thing that counts, it doesn't have to be practicle...as long as it's fun.

I've gotten this far with it (and want to try worstje's idea), so I'll just keep playing with it until I (win) can figure out what to do with it. Let me know if you to do anything with it and I'll work that in too.

Wifi connections are always a hassle and I keep looking for a helpful utility, but there are none.

...Ya never know where this project could end up going.

@worstje - I do appreciate the input, but I found another way around the issue using existing code. If you drill into IShellFolder just a tad deeper, it will tell you what the window/display name of the requested GUID is. So even if some clown decided to name their adapter "Barney's Desert WiFi Emporium" I can still test for a window by that name on-the-fly. So the non-cooperative message loop has been replaced with:

if (SUCCEEDED(hr)) {
            STRRET pStrRet;
    ZeroMemory(&pStrRet, sizeof(STRRET));
    hr = pShellFolder->GetDisplayNameOf(pidl, NULL, &pStrRet);
    if (SUCCEEDED(hr)) {
        hr = StrRetToBuf(&pStrRet, pidl, szTarget, GEN_BUFF);
        if (SUCCEEDED(hr)) {
            bGood = TRUE;
        }
    }

    Sleep(2000);
    while(bGood && FindWindow(NULL, szTarget/*L"Wireless Network Connection"*/)) {
                 // Nothing to Do Really, Just Hang-Out and Watch the Window.
    }
}

Quote from: Stoic Joker on January 25, 2011, 09:39 PM

...Ya never know where this project could end up going.

Hey!  If you do actually do this, I can offer a lot of suggestions (as usual), and I think it would be VERY handy for people with laptops.  I don't care what anyone says, wifi is a hairy beast once you get involved with all the settings for security and all.  And all the interfaces suck for them.  But I kind of understand why now if Windows doesn't even have a way to access that one window.

It's not so much that Windows can't access that window, it's that the window needs an adapter target specified for it to be opened with. That little detail has been bugging the shit out of me for next to forever ... Which is why I jumped at taking a crack at this after wraith808 dropped an entry point into our laps.

I started a thread asking for this a while back:
http://www.donationcoder.com/forum/index.php?topic=23791.0
See if you get any ideas from there, and I'll be more than happy to offer suggestions, solutions, etc.  I'm only limited with programming, that i can't do.

Yes, I remember that one. For now I just want to turn this into a viable loader widget (so I can get back to the other 9 projects that are hanging over my head). To that end I'm going to add a NIC picking dialog as the (first run) default action if the GUID is not specified in the command line (instead of the error message). Then the the selected GUID can be stored in either the registry, or an .ini file (I'm leaning toward the .ini option). So if you got a preference there let me know.

Well SJ, looks like you're going to earn your Superboy badge

Well Stoic, if you are planning on making a full fledged program out of this, here are my ideas.  I don't know how feasible any of this is programmatically, they're just end user ideas.

Is there a way for you to have a dialog on just the first startup or somewhere in the option settings where the window detects all the adapters currently installed in Windows? Then the user clicks on the adapter desired, and the program runs from there without anymore dialog on startup.  Now, if the user wants to change adapters, he can do so from the menu or something.

Yes, I just replace the (GUID missing) error message with the Pick your NIC dialog. Whichever NIC the user picks then gets saved to the .ini/registry (depends), and is automatically used to display the WiFi networks available for it.

command line, ini is ok, but it would be better if it could programmed in the interface.  So if you need options for autostart, suppressing the startup dialog, exit/minimize on close, system tray, etc., it would be better to have those all as checkboxes or something in a options dialog.  But if that's too much work, text file or command line works also.

Also keep in mind having profiles to be used as a portable application?  Yeah?  Then you can run it on other computers and store the settings when you are done.  That would be really cool.

Command line option is already there so (no sense in pulling it out) it can be used as a fall-back suppress everything and just run option. I'm still on the fence as to what to do for settings storage and a UI. If I go systemtray then the registry makes more sense. If I go straight portable then the .ini (with save optional) makes more sense. Command line only, with multiple shortcuts, would be a Quick-N-Dirty "profiles" solution (albeit rather cluttered)...But if the user has to stop at a "Pick Network A, B, or C" dialog then we're back to multi clicking things.

Ironically the "simplest" thing might just be to do all-the-above and let the user decide how they want to fire-it-up.

Quote from: 4wd on January 26, 2011, 04:09 AM

Well SJ, looks like you're going to earn your Superboy badge

Hahahaha...damn right he is.     Welcome to the club...   

I'm a little sketchy on this part, should I be flattered, frightened, or both...

Just in case anyone is wondering, I've spent the last few days getting my ass kicked by the ComboBox control for the NIC picking GUI. Getting the NIC list from the registry was a breeze ... How to get it displayed to the user however is proving trickier than I'd anticipated.

Poo...

Maybe the strange antics of the little cubic motorcycle creatures will calm me as I continue this quest.

Quote from: Stoic Joker on January 26, 2011, 01:00 PM

I'm a little sketchy on this part, should I be flattered, frightened, or both...

Definitely frightened!

Why?  Probably because you leave yourself open to repeat custom.

That just might be true...

Okay, got it working (finally). There are currently no (.ini/reg) save functions as of yet. So it is on a perennial first run basis at the moment. But a general feel of the app can be had so I thought I'd toss it up for comment.

When the dialog opens, caret focus is on the adapter list, so just arrow down to the adapter wanted and hit enter.

Let me know if I'm on the right track here SB.

WiFi.exe (64.0 KB)

Thanks!

I was thinking, if "we" bolt this thing down with a SysTray icon and Registry stored info. It could be (configurably) HotKeyed ... That's about the fastest access route I can think of ... Sound good to anybody?

Okay, got it working (finally). There are currently no (.ini/reg) save functions as of yet. So it is on a perennial first run basis at the moment. But a general feel of the app can be had so I thought I'd toss it up for comment.

When the dialog opens, caret focus is on the adapter list, so just arrow down to the adapter wanted and hit enter.

Let me know if I'm on the right track here SB.
(see attachment in previous post)

I'll report on Monday, I don't have anything to test it on right now.

Quote from: 4wd on January 30, 2011, 06:24 PM

Works here on my netbook but lists every interface, even ones no longer plugged in.

I'd been wondering if that would be an issue, but wasn't sure how common the disabled adapters problem would be.

It reported a 802.11n adapter I haven't had plugged in for 6 months, another 802.11g adapter (unplugged) and a Huawei 3G modem (unplugged) as well as the normal LAN interface.

Given my (I'm beginning to suspect insane) habit of working in straight Win32 API C++, no. But I might be able to do something like that to eliminate the disabled adapters.

The AutoIt stuff seemed to be based on this C/C++ code into the Native WiFi API and I was thinking you could use that to get the string names of the current accessible adapters and then match against the ones you get from the registry to eliminate the others.

But what I know about C could be written on a pinhead in crayon, so I'll climb back under my rock