Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

Clicking on the close button does not appear to have any visible effect.

I can find no issues with either the Close button or pressing <Esc> with WinButtons having focus. Is there perhaps an extra (older) instance of WinButtons running that's waiting for a condition/hanging/cycling perpetually? (You could check that using Process Explorer or Task manager)

I can find no issues with either the Close button or pressing <Esc> with WinButtons having focus. Is there perhaps an extra (older) instance of WinButtons running that's waiting for a condition/hanging/cycling perpetually? (You could check that using Process Explorer or Task manager)

I don't think there was, and I reproduced the issue just now. I am also running XP SP3. Similar results to cranioscopical -- pressing the escape key works while clicking on the close button doesn't seem to.

Quote

Update will be posted later this evening.

Sounds good.

BTW, any chance of being able to drop WinButtons config files on WinButtonEdit.exe to have the config file opened up in WBE? That doesn't seem to work here.

Similar results to cranioscopical -- pressing the escape key works while clicking on the close button doesn't seem to.

I've already found out it is to do with the Extended Style parameters of the window. Guess Vista/Win7 enforce the minimum required to have a working Close button, while XP doesn't Been fighting this before to get rid of a border when having a background color set I'll hold the update until I find something workable or it gets too late here and keep this as a todo

So, a usable solution for the non-functional Close button on Windows XP was found: It shouldn't be combined with the movable option.In this particular case (XP, and options: border, closebutton and movable) the movable option is ignored. 'movable' was originally implemented to be able to move a border-less WinButtons window, but the caption bar is available so the window can still be moved around the screen (the movable option could easily be mis-interpreted )

Also fixed was the defective :dropItem1: feature as reported by ewemoa, it was to do with borders checking and 1-off, a common pitfall when itterating (irritating?) over an array in a 0-based setting. If there where 2 or more items dropped it would have worked for item1

So, a usable solution for the non-functional Close button on Windows XP was found: It shouldn't be combined with the movable option.In this particular case (XP, and options: border, closebutton and movable) the movable option is ignored. 'movable' was originally implemented to be able to move a border-less WinButtons window, but the caption bar is available so the window can still be moved around the screen (the movable option could easily be mis-interpreted )

I think I get it -- if I choose both closebutton and movable, I won't be able to move the window via the border, but for the close button to show up the border option needs to be specified, and if that's specified, there will be a caption bar, and if there's a caption bar that can be used to move the window...

That is what I see with the latest update and that seems fine to me.

Quote from: Ath

Also fixed was the defective :dropItem1: feature

Thanks! Tested it here and seems to be working

Quote from: Ath

I'll be searching for a final solution for this Closebutton/movable/Windows XP combination-issue...

if I choose both closebutton and movable, I won't be able to move the window via the border

Almost correct.If movable is set, then the window can be dragged around by clicking on the window-background and dragging it. If border + closebutton are set, then you can drag it around by grabbing the window by it's caption. On XP you can't combine border + closebutton + movable, as then the Close button stops working, for reasons yet unclear to me. Not sure this is solvable, though.Hope this clears my previous description.

If movable is set, then the window can be dragged around by clicking on the window-background and dragging it. If border + closebutton are set, then you can drag it around by grabbing the window by it's caption.

And, being a lazy [insert your term here] I'll repeat my earlier question viz., Any chance of changing .ini to something different and making WBedit the application to handle that? I mean associate a different .something file extension with WBE.

The point being that, when testing, a double-click on a file name would be a quick(er) way to load a selected .ini into WBE. In my view this would be especially useful since WBE can have multiple instances. Your view may be entirely different

If not, presumably I can set WBE to handle .ini on a temporary basis and just toggle between that and my standard .ini association.

Oh you want to register the file extension, ah, that can be done, but I'll think/search about the extension to use, as most 3-letter combinations are in use already.What I already thought of: .wb, .wbut, .wbe, .wbtc, but suggestions are welcome I'll have to change that extension to be the default for WinButtons as well (and fall back to WinButtons.ini if not found), or possibly just like the AutoIt installer offers: select between WinButtons and WinButtonEdit as the default "open" action. (And also add some Explorer context-menu options for Open With.../Edit with WinButtonEdit/Run with WinButtons, etc. And then options to de-register these )

Regarding the file extension topic, while I can appreciate the convenience of file associations, I'd prefer that it not be a requirement for a system's registry to be modified for my own case and I'm willing to forgo the convenience. So...do you think there will still be a portable version of the application available?

BTW, any chance of being able to drop WinButtons config files on WinButtonEdit.exe to have the config file opened up in WBE?

Would you expect it to run 3 instances of WBE, if 3 files are dropped on a single instance, or just open the first and ignore the rest?

I think the former would be more useful, but wonder about the potential persistence-consistency issue for multiple instances of WBE running...When I wrote my request, I was sloppy in my wording. What I had in mind might be more accurately described by:

"...any chance of being able to drop a WinButtons config file on WBE to have the config file opened up in WBE"

I'd prefer that it not be a requirement for a system's registry to be modified

That is for sure not a requirement, just an additional option, available from the Options menu, and by selecting it again it will be fully removed assuming the proper privileges are available (else it should silently fail both actions). (It's finished already, but I'm testing it some more)

BTW, I've chosen the extension .wbuc for the time being. I'm working on some minor issues with WBE and teaching WinButtons to also support that extension, so I'll probably release tomorrow (it's rather late here already).

WBE supports Drag&Drop, configurable for either a single file or multiple files into multiple (new) WBE sessions (details in the readme)

The .wbuc file extension can be easily associated with WinButtonEdit or WinButtons (when in the same directory)

Several bugfixes

The stuff can be downloaded from the original release post, it's a zipfile with all compiled binaries, (AutoIt3) source for WinButtons and includes an updated readme for both WinButtons and WinButtonEdit.

If you might find any bugs, or have more feature requests or other remarks, please report here, so I can improve myself and the software.

WBE supports Drag&Drop, configurable for either a single file or multiple files into multiple (new) WBE sessions (details in the readme)

This works for me sometimes. My current guess is that it works for .wbuc files but not .ini files.

BTW, regarding the WBE drag and drop feature, what I had in mind originally was dragging and dropping on to the .exe and not a running instance -- though this is nice too Sorry if my phrasing was unclear / wrong. Do you think this "drop on to .exe" feature is a possibility?

If .wbuc is now the preferred file extension, do you think it would make sense for the default WinButtons.ini to be renamed to use the new file extension?

I didn't do that on purpose, as users would be surprised to see the original WinButtons configuration where they may have created a personal one with the old filename, and the .wbuc file gets preference...

WBE supports Drag&Drop, configurable for either a single file or multiple files into multiple (new) WBE sessions (details in the readme)

This works for me sometimes. My current guess is that it works for .wbuc files but not .ini files.

It should work equally well for both .wbuc and .ini files (these are the only supported extensions, ATM). One peculiarity you could see is that if the current WBE instance has a file opened that is in the set of files dropped. That already open file is kinda ignored, but left open in the original WBE instance. If multiple drop files is enabled and more are dropped, the extra files should open in new WBE instances. If multiple drop files is disabled, nothing might happen when multiple files are dropped that include the file already open in WBE.

I'd have to figure out how to do that, I'm not familiar with that feature (aka: I never open files that way myself). If the file association is set to open with WBE, a double click would suffice If preferred I could add 'Edit with WinButtonEdit' to the context menu in Explorer? (And change 'Open' to 'Open with WinButtonEdit')

If .wbuc is now the preferred file extension, do you think it would make sense for the default WinButtons.ini to be renamed to use the new file extension?

I didn't do that on purpose, as users would be surprised to see the original WinButtons configuration where they may have created a personal one with the old filename, and the .wbuc file gets preference...

Ah, the joys of backward-compatibility...

On a related note, are there some reasons why it is that some of the dialogs for WBE don't have both *.wbuc and *.ini for their value in "Save as type"? For example, "New" and "Save as..." both lead to one where the value is only *.wbuc...

Ah, btw, choosing File -> New and then pressing the Cancel button leads to the file dialog appearing again here...I get a feeling of Deja Vu.

WBE supports Drag&Drop, configurable for either a single file or multiple files into multiple (new) WBE sessions (details in the readme)

This works for me sometimes. My current guess is that it works for .wbuc files but not .ini files.

It should work equally well for both .wbuc and .ini files (these are the only supported extensions, ATM).

I'm sorry to say that it doesn't seem to work here for ini files that I have tried. I created a file via WBE called "Test.ini" (a new file, one button, saved as "Test.ini", quit WBE, open WinButtons.ini, then drop "Test.ini" on to the treeview). Whether the "Multiple files dropped..." is enabled or disabled appears to make no difference.

I tried opening various appropriate *.ini files manually (works fine -- e.g. start with the newly created Test.ini), then followed this by dropping any of the other appropriate *.ini files on to the treeview -- the result was no change in the treeview.

I'd have to figure out how to do that, I'm not familiar with that feature (aka: I never open files that way myself). If the file association is set to open with WBE, a double click would suffice If preferred I could add 'Edit with WinButtonEdit' to the context menu in Explorer? (And change 'Open' to 'Open with WinButtonEdit')

Hmm...well if it's too much trouble, please punt on it (at least for now...). Since I don't do file associations because of the registry involvement, context menu entries in Windows Explorer fall under the same class of things I don't go for either, so unless someone else asks for it...

don't have both *.wbuc and *.ini for their value in "Save as type"? For example, "New" and "Save as..." both lead to one where the value is only *.wbuc...

They are both there (that's the same dialog, btw), but I seem to remember having naming-issues when both specs where there in the same selection. I'll retest that. Maybe I should add *.* to that dialog too?

Ah, btw, choosing File -> New and then pressing the Cancel button leads to the file dialog appearing again here...I get a feeling of Deja Vu.

That's on purpose, you have to choose a filename (sorry for the fuss, though).

I think I'll re-do this option a bit for the next release.It now asks to save the just created empty buttonset to a file, but I probably should ask the new filename first, and on cancel do nothing, not even clear the buttonset in memory. That sounds more as it would be expected, in UX terms.