Has anyone used #AbtCwDateTimePickerView

Hi Everyone,

I'm trying to use #AbtCwDateTimePickerView (dropped in my window from the Windows Controls category).  It works fine in the development environment but once I package things go south.  It will drop down but looks odd.  Sometimes a can select a date but more often than not it will lockup the program and burn about half of my two cores.

Is this just me?  Is there something I should be doing differently?  I this a known problem?

Lou

Hi Wayne,

Thanks for the idea.  I really thought it would help as I didn't have a manifest file for the executable.  I use the executable created by the "Make Executable" button on the main organized window, which looks like a copy of nodialog.exe.  But it didn't do any better.  I also changed the name inside the manifest to match the executable but no joy.

Could there be a DLL that I have out of sync between development and production?  I don't think they are but I will check again.

A side note to Instantiations: If the manifest file is important, maybe the  "Make Executable" button should create one when it copies the executable and packages the image. 

Lou

Lou - just a hunch that it may have to do with the version of Windows controls you're picking up from the OS by virtue of the manifest (or no manifest).  Try copying the nodialog.exe.manifest to your runtime environment if you are using nodialog.exe (or whatever you've named the .exe, name manifest after the .exe).

Hi Wayne,

Thanks for the help.

Lou:

I don't think it makes sense for a packager to create a manifest file.  In our runtime environment for the client, we run a renamed nodialog.exe.  The packager doesn't know that.  If the packager created a manifest file, we'd have to remember to rename it and stick it in the runtime environment.  But we'd really only have to do that once.  So we might as well not have the packager do nothing - we just have to remember to stick the official manifest file (renamed) into the runtime environment once.  I admit I don't know if there is documentation saying you should do that.

What you may want instead is the manifest being stuck right into the .exe.  That is possible.  However at <a href="https://groups.google.com/forum/#!searchin/va-smalltalk/manifest/va-smalltalk/V86CJn7exDU/uNd3bjtfda8J" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!searchin/va-smalltalk/manifest/va-smalltalk/V86CJn7exDU/uNd3bjtfda8J';return true;" onclick="this.href='https://groups.google.com/forum/#!searchin/va-smalltalk/manifest/va-smalltalk/V86CJn7exDU/uNd3bjtfda8J';return true;">https://groups.google.com/forum/#!searchin/va-smalltalk/manifest/va-smalltalk/V86CJn7exDU/uNd3bjtfda8J I convinced John of Instantiations not to do that, since then our application would automatically get stupid behavior thanks to Windows - which I can avoid now by simply not copying that manifest file.

The problem seems to be solved with some help from Wayne and Solveig.  I had to change the registry to prefer external manifests.  That got windows to pick up the manifest and everything worked as expected from then on.  I think it may be a good idea to include/embed the manifest in the executable.  I would hate to have to tell my users that they need to change their registry.  So I'm looking into that.  Thanks Wayne and Solveig.

Lou

Hey Wayne,

You are more knowledgeable than I am now.  I hadn't known about a registry entry to prefer external manifests.  And I've never done "Make Executable".  But hearing that it makes a .exe, it does seem reasonable to conditionally (?) make a manifest file or even embed it in the .exe.

But to answer your question, we use the packager ("Browse Packaged Images" menu item).  This creates an image (icx file).  Users invoke a shortcut which invokes the .exe (nodialog.exe say) with the image file specified on the command line.

Hi Everyone,

For those that are interested, it was the need for a manifest file that caused the odd behavior with the date picker.  I wasn't suppling a manifest file and when I did for some reason Windows didn't read it.  There is a program called "touch" that will change the date/time of executables (or anything).  Having a new date/time somehow get Windows to read the manifest file and then all is well.

I have some Smalltalk code (basically scripts that I keep in the class comment of the main object of a program) that I run as part of packaging.  I have added some code to copy an appropriate manifest (one for GUIs and one for NT services) and for Windows NT services the executable (for GUIs the executable is supplied by VA Smalltalk) and then call #CfsFileDescriptor>>touch: to change the date/time of the executable.  This looks like it insures I have an executable and manifest the Windows will be happy with.

Lou

P.S.  I'm also using the zip stuff in these scripts that I talked about in another thread to bundle things together.