The 27 July 2009 build (5716) is out.

[Acki]

is there a way to disable the ".dll" for the lib name ???

Search the forums.

ahh, so there is a way, I'll have a search, thx...

but what about the Ctrl-Tab problem ???  

EDIT:
so I found the options "Auto-generate filename prefix" and "Auto-generate filename extension"...
but it seems to be the problem like with Ctrl-Tab !!!
the check boxes have no effect, plus it generates the extension ".exe" instead of ".dll" !!!

to illustrate some screenshots:

Auto-generate enabled and extension entered:


Auto-generate enabled and no extension entered:


Auto-generate disabled and extension entered:


Auto-generate disabled and no extension entered:

[Loaden]

another problem when creating a DLL...
let's say I'm compiling a DLL called "Irrlicht.dll", now the lib file is named "libIrrlicht.dll.a"...
but I don't want the ".dll" between "libIrrlicht" and ".a" !!!
now I either need to rename the lib manually or change the project settings for all my projects... 

is there a way to disable the ".dll" for the lib name ???

Since after a SVN version, it becomes the case.
I do not want that too.

The same problem: how to remove the middle of the ".dll"?
Thanks!

[Ceniza]

Morten: can you see now that we do not like that behavior?

[MortenMacFly]

Morten: can you see now that we do not like that behavior?

...no?!

The point is:

The behavior we had before did not work for the cases I told you. In addition users complained.

The behavior we have now works on all cases but is less "intuitive". In addition users complain.

So - what's the better choice? Make it an option? What's the default value then?

[Ceniza]

Morten: can you see now that we do not like that behavior?

...no?!

The point is:

The behavior we had before did not work for the cases I told you. In addition users complained.

The behavior we have now works on all cases but is less "intuitive". In addition users complain.

So - what's the better choice? Make it an option? What's the default value then?

The default behavior should be that we have always seen and expected: file.dll and libfile.a.

When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin), he/she should then specify it somehow using a non-yet-existent-option. Splitting the output file name into name and extension fields with, probably, a checkbox saying something like "Use this extension instead" could help. If the checkbox is not selected, the extension field should not be editable. An extra read-only output field could be added to show the user the final result of the selected options (probably two: one for the file name, and one for the library name).

[MortenMacFly]

When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),

Notice that this was only *one* problem.

Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.

[Ceniza]

When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),

Notice that this was only *one* problem.

Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.

What was wrong with System.Management.DLL again? (I have forget only memory)

[jens]

When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),

Notice that this was only *one* problem.

Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.

What was wrong with System.Management.DLL again? (I have forget only memory)

If I remember right, it was turned int "System.dll" .

[Ceniza]

When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),

Notice that this was only *one* problem.

Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.

What was wrong with System.Management.DLL again? (I have forget only memory)

If I remember right, it was turned int "System.dll" .

Well... with an extension field you should not have that problem.

Output file name: System.Management (user input)
[ ] Use custom extension (unchecked)
Custom extension: dll (default shown, empty, previous value, ...)
Full output file name: System.Management.dll (read-only)
Full import lib file name: libSystem.Management.a (read-only)

Is it too bad an idea?

[MortenMacFly]

Output file name: System.Management (user input)

Right - I should have been more precise: It's a wx function that tricks us so you cannot distinguish by a base file name "System.Management" whether it has an extension or not. Cause wx will report "Management" as extension. So is than the extension you want or do you need to add another ".dll"? How do you differ? What happened in the past was than if I enabled  "auto ext" and put "System.Management" as file name it resulted not in System.Management.dll but in System.dll because we remove any existing extension before automatically adding the new one. If you don't do that a library called "system.dll" with "auto-ext" enabled would become "system.dll.dll" and again we surely will have complaints.

To make it short: If you see a way tat copes with all the cases correctly and looks "nice" - tell me or better just implement it. I just don't see any. All I did was at least making it functioning correctly because that has highest priority for me and not if the file names are "correct". Cause again: GCC handles the files just fine the way it is now.

[Ceniza]

Output file name: System.Management (user input)

Right - I should have been more precise: It's a wx function that tricks us so you cannot distinguish by a base file name "System.Management" whether it has an extension or not. Cause wx will report "Management" as extension. So is than the extension you want or do you need to add another ".dll"? How do you differ? What happened in the past was than if I enabled  "auto ext" and put "System.Management" as file name it resulted not in System.Management.dll but in System.dll because we remove any existing extension before automatically adding the new one. If you don't do that a library called "system.dll" with "auto-ext" enabled would become "system.dll.dll" and again we surely will have complaints.

To make it short: If you see a way tat copes with all the cases correctly and looks "nice" - tell me or better just implement it. I just don't see any. All I did was at least making it functioning correctly because that has highest priority for me and not if the file names are "correct". Cause again: GCC handles the files just fine the way it is now.

I am giving you a solution. It implies that you won't try to guess an extension at all. You read that field 'as is'. If the user has not selected an extension of his own, dll/so will be used by appending it to the base file name. If you want an extension of your own, then you check the checkbox and write the one you want. The result will be the base file name + . + the extension.

[courage]

Hello, I have a bug report. Every time when I open the main frame window in wxSmith, and I see the ckecked menu item will now be set unchecked in the MenuBar editor.

[cgarcia109]

*.dll.a

I didnt liked this too in the first place, but now i like it. Maybe its not de cool name youre used to, but its just a name, and i see some advatages it make clears is a stub lib to a dinamic link library, and differentiate(sp?) from a static lib, in the case you need to build both without making every library goes to a different place. What would make more complex configure dependants projects.
Actually i changed my mind and i like this way.

[MortenMacFly]

Actually i changed my mind and i like this way.

Thanks! You are the first saying so which makes me glad. I like it, too obviously.