Update: Ugh... how embarrasing. Ok, here's the story -- I'll try and keep it short.

JComboBox has two callbacks for adjusting the Popup Listbox: -popupcreate and -popupmodify. Originally, these options were used to configure the Listbox at two different points prior to displaying the Popup.

JCombobox has a large section of code that tweaks width, height and other positioning information depending on values of various options. One of these two callbacks was used to modify the JComboBox before this block of code was executed (-popupcreate), and one after the block had been executed (-popupmodify). The first would allow someone to make changes such as to the options contained within the JComboBox, but still take advantage of the positioning code and other misc logic, and the second option would give someone the final word on the configuration/layout of the popup prior to displaying it, allowing the developer to override any options I saw fit to set.

It looks like at some point, I must have decided that option number 2 was insufficient, and instead of modifying what I'd set, I decided to offer someone the opportunity to completely control the positioning and replace my logic with theirs. I put this weighty responsibility into the popupcreate option, which explains why the popup didn't look good and was positioned incorrectly. You must not have provided positioning logic.

When I changed this, I think I went too far, and provided too much flexibility. In retrospect, this was a pretty bad idea -- I think it's highly unlikely that someone would want to go through all this trouble... If so, they would likely be rolling their own ComboBox implementation.

I think I'm going to change it back to the way it was, provide an explanation, and options for those who have implemented that option. I should have a new release tomorrow sometime... For now, see if -popupmodify will work for the short term (or put a call to PopupCreate within your -popupcreate sub). If you'd prefer, I'll probably have a fix in by tomorrow - I've had time to consider the scope of change and it shouldn't be a big deal, but I'd have to run it through tests, etc.

BTW: Did you come to any conclusions on how or if you're going to refactor your large Perl/Tk app?

Thanks,

Tk-JComboBox 1.12 has been uploaded to CPAN. I think it will resolve this issue. This release also includes minor updates to the docs and test cases. It also features a new examples directory that should grow larger over time. Here is a relevant example that demonstrates -popupcreate

use Tk;
use Tk::JComboBox;

my $mw = MainWindow->new;
my $entry = $mw->Entry->pack;

my $jcb = $mw->JComboBox(
   -choices => [qw/one two three four/],
   -entrywidth => '16',
   -highlightthickness => 0,
   -listwidth => '16',
   -mode => 'readonly',
   -popupcreate => \&addItems,
)->pack;

MainLoop;

sub addItems {
   my @items = split(/ /, $entry->get());
   $jcb->removeAllItems;
   $jcb->configure(-choices => \@items) if @items;
}
[download]

For versions 1.11 and earlier the following serves as a partial workaround to the issue with -popupcreate. The last line can be included in callbacks to take care of Popup layout/positioning issues.

sub addItems {
   my @items = split(/ /, $entry->get());
   $jcb->removeAllItems;
   $jcb->configure(-choices => \@items) if @items;
   $jcb->PopupCreate;
}
[download]

Note that this will still have a problem if the JComboBox is empty, because the popupcreate callback will not get triggered. Version 1.12 accounts for this.