Scrollbar bug in application builder

I seem to have found a bug concerning the front panel scrollbars when creating an executable with application builder.
My vi runs fine in Labview. It also runs fine as an executable with everything at defaults.
However, trying to remove the scrollbars from the front panel, I can build executables that hang up upon running.
Executable hangs up when:
- setting the vi property 'windows appearance' to dialog.   (application builder set to use vi settings)
- in application builder, sourcefile setting: setting 'use scrollbars' to "don't use vi settings" and value "not checked"
What's really weird is that sometimes those troublesome executables do work.   The executables compiled with the 'dialog' option only seem to work once, and then not anymore.    While the one with the no-scrollbars option set in application builder seems to hang the first time, but work fine after that.   Except that it does show scrollbars....
The executable does work without front panel scrollbars when setting the vi property 'windows appearance' to 'top level application' and application builder settings to 'use vi settings'.

Hi Rebecca.
I'm using Labview 8.2 on Windows XP SP2 for developing. The PC that the .exe should run on has the LV 8.2 runtime installed, also on Windows XP SP2.
I've attached two executables of my program: 'works' and 'doesn't work' which were compiled with the scrollbar on and off.  Also included the source distribution. The "Micro4 Advanced Multiple Injections LV82" is the main program.   (Hope I did the distribution right... it's the first time I'm using this project thing...)
I've been testing a bit more myself...  I now noticed that both .exe's work correctly on my developement PC, but only the one works on the runtime PC...
Attachments:
doesn't work.zip ‏220 KB
My Source Distribution.zip ‏336 KB
works-ok.zip ‏400 KB

Similar Messages

Stand-alone application generates error with function 'Ramp Pattern' (bug in application builder?)

Hello,
in my program a main.vi links to a sub-VI via 'open VI reference' and 'invoke node'. In this sub-VI the function 'Ramp Pattern' is used. The program itself runs normally, but if I build a stand-alone application using application builder I get an error message 'error 1003 occurred ..'. I believe this error is directly related to the build specifications which are as follows: the main.vi is referenced in a main build specification, the sub-VI in its own specification where the target is a LLB.
I appended an example-program that exhibits the error (when executing 'Application.exe' and pressing 'calculate ramp'). The error does not occur when disabling the 'ramp pattern' function and rebuilding the application.
I would rate this to be a bug in the application builder and would appreciate any help on how to solve this problem. However, due to the structure of the whole program the sub-VI has to remain in its own LLB.
Attachments:
RampPattern.zip ‏198 KB

There can be reasons why a VI might appear broken when loaded from an executable. For example, if you have different versions of the same VI or enum that differ in such a way as to break the calling VI, that can cause a broken arrow when loaded from the executable. If you have DLLs being called and the runtime engine can't find the DLL, that can cause a broken arrow that you might not see otherwise. Finally, there is a bug related to a VI appearing broken when its not.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Text field with autocomplete: little bug in application builder

Hi,
I just noticed that the application builder complains when a text field with autocomplete is defined with a named LOV containing a single column value (Apex 4.0.2.00.06).
I created the text-field with a dynamic LOV (please specify in the docs that autocomplete requires single column queries!), then I used the "Convert to named LOV" task link to convert it to a named LOV and it works perfectly, however as soon as you attempt to change some other attribute for the item, it will throw the following error:
1 error has occurred
Using a named list of values (LOV) is only supported for item types which require at least two LOV columns.As i said, the named single column LOV works just fine with the autocomplete, so the error message seems to be also misleading.
Flavio
http://oraclequirks.blogspot.com
http://www.yocoya.com

Hi Surya,
the "Text Field with autocomplete" is really just an autocomplete widget and doesn't behave like a LOV. But we are planning to release an item type plug-in which solves both of your requirements.
Regards
Patrick
My Blog: http://www.inside-oracle-apex.com
APEX 4.0 Plug-Ins: http://apex.oracle.com/plugins

Display Bug in LV 8.20 Application Builder

There seems to be a minor bug in the displaying of the "VI Settings" in the application builder for LabVIEW 8.20.
The problem is in an executable build spec, in the "Source File Settings" category.
Select a sub VI in the tree, then uncheck the select box for the "Remove Panel" property. Now select any other VI in the tree, then go back to the one you unchecked the "Remove Panel" box. You should see that the box is now checked.
If you don't do anything else and just select "OK, then go back into the build spec, you'll see that the property was correctly saved as unchecked. So it looks like it's just a display problem.
I've made sure the VI I try this with does not use any property nodes and it is not marked as a dynamic VI. I can reproduce this on two machines running Windows XP Pro SP2 and LabVIEW 8.20.
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

In addition to Ed's
comment, I would like to say that this unexpected behaviour is not
always appearing. I have just seen following while editing this text :
I have unchecked the Remove Panel box for all the UI VIs (all are
located in the same directory). When scrolling through the different UI
VIs in the Soure File Settings, the box was unchecked for all the VIs.
Without closing the Source File Settings window, I switched to
Developer Zone and switched back to the Source File Settings. For some
UI VIs, the Remove Panel box was checked. I closed the window and
opened it again, the box was unchecked again for all the UI VIs.
But I have also encountered the case that when scrolling through the
VIs to try to uncheck this setting for all of them, it suddenly appears
checked again for a VI for which it was unchecked or unchecked for a
before checked VI.
You finally end with a very unclear situation and it may be that the
Remove Panel is really checked for some VIs. At least, in some cases,
the built EXE could not run because of missing front panels. I can't
remember the exact error messages when running the EXE but they
mentionned the name of the VI and something about missing ressources. I
opened the .lvproj file and noticed that the "Remove Panel" property of
these VIs was set to TRUE. After modifying these settings and
rebuilding the EXE, it ran as expected.
In development, I
normally uncheck "Allow user to resize window" of the UI VIs because
this setting can unfortunately not be changed when configuring the
executable. In the "Source File Settings" I uncheck all options of "Use
VI Setting" for these UI VIs and I only check "Auto-Center" (all VIs)
and "Window is Modal" (some VIs).
There is another problem with the application builder that I would like
to mention. For (at least) following settings, the development settings
of a VI will not be overwritten by the Source File Settings when
building the executable :
- Window has title bar
- Show Menu bar
- Show Toolbar
- Show Scroll Bars
This is also very annoying because you will need to change these
settings in the development environement in order to get the expected
appearance in the executable.
LV8.2 English / WXP SP2

Bug? Application not appearing in Application builder

Version 3.1.2.00.02
I have an application 102 which is translated to japanese as application 103 in my workspace - training
I have another application in a different database with application number 102 in workspace - develop.
I export application 102 from develop and import it into training. I select Auto Assign New Application ID. This creates the application with ID 103!
I was able to work and make changes and do everything on this new application. However, when I check in the application builder, I cannot not see this application. And when I try to run the application 102 in japanese (translated), then, it fails with an error.
Though I cannot see the new application 103 in my builder, I can run the application by making changes in the URL and if I click on 'Edit Application' link, then, I am able to make changes and work on application 103.
I realised that this is a corrupted version, and deleted my japanese translation of 102. This deleted my new application as well.
Is this a bug ?

Hi Naveen,
It will be most probably because of Security not defined for this new application in the "Member Access profile". Please check.
Thanks & Regards
Arun Kumar S

Application Builder Bug?

I created a Calendar region in an application on htmldb.oracle.com (version 2.0.0.00.49), resulting in the creation of 3 region buttons: "Previous", "Today" and "Next", displayed on the page definition screen in this order but all with sequence number 30.
In the Application Builder>Application>Page Definition>Edit Page Buttons screen, I made a change to the "Previous" button and then clicked the [>] button to move to the next button definition. This displayed the Edit Page Buttons screen for the "Today" button, but the [>] button was not available to move to the "Next" button. Similarly, in the "Next" button definition, the [<] button isn't available to move to the preceding "Today" button.
Not a massive issue, but a bit awkward.

Hi Oliver,
comment attributes do normally only save up to 4000 characters. I will file a bug to restrict the textarea to 4000 chars.
Regards
Patrick
My Blog: http://www.inside-oracle-apex.com
APEX Plug-Ins: http://apex.oracle.com/plugins
Twitter: http://www.twitter.com/patrickwolf

Bug in Application/Query Builder?

I created an SQL query using the query builder in 10g. It didn't work. I pasted the same query into SQL Commands. It worked. I pasted the same query into the Application Builder. It didn't work. (By didn't work, I mean it gave me 500 rows of a 2000+ row view.) Has anyone come across this before? For the life of me, I can't figure out what's going wrong.

Hi
I think, it isn't a bug.
Per default all tabular forms are limited by 500 rows.
You see at the end the message "row(s) 1 - 15 of more than 500"
Greetings
Sven

DOC BUG: Oracle Application Express Application Builder User's Guide 4.1

Oracle® Application Express Application Builder User's Guide
Release 4.1
Part Number E21674-03
+§ HTML Header and Body Attribute+, Table 8-4 has:
>
Attribute: Page HTML Body Attribute
Description: Enter text or HTML you want to appear before the page template footer.
>
This is the description for the Footer Text property, correctly described in Table 8-5. Table 8-4 should have something like:
>
Attribute: Page HTML Body Attribute
Description: Enter HTML attributes to be specified for the page <tt>body</tt> element by replacing the <tt>#ONLOAD#</tt> substitution string in the page template.

Anthony
Thanks for picking that up.
If you hadn't already noticed it, could I bring the +{thread:id=2285521}+ thread to your attention? I've confirmed that finding and would appreciate an explanation.

APEX documentation bug: Application Builder User's Guide

Oracle® Application Express Application Builder User's Guide Release 4.0, chapter 12
>
Viewing Debug Deports
>
Should read "Viewing Debug Reports".

Thank you for noting this. I've passed the information along to the Application Express writers.

Including a Pre-Built LLB in Application Builder 8.X

I have just recently updated some old code to 8.5.1. This code contains many dynamic calls to VIs located in pre-built LLBs (LLBs that were saved prior to application builder). This application is also compatible with a priority plug-in architecture. So when creating an application or installer in app builder 8.X, how does one include a LLB file? I do not wish to build it. I just want to include it the same way you may include a text file or someother type of source file. LLB files do not show up as individual files in the Project Manager.

AstroGlen wrote:
I would like to create an installer that uninstalls the previous version of software (which was written in 7.1.1). I am assuming it is necessary to make edits to the "registry" category in the installer properties. I am also assuming that I would need to enter the product code for my application. This is the code found in the 7.1.1 application builder \ installer settings \ Properties button. But i do not know the particulars of what needs to be done.
I think when you install an application created/built using a higher version of LV, it ll automatically overwrite any previous version(s) of that application installed in the target PC. We may not need it to be uninstalled manually. Did you try this?
- Partha
LabVIEW - Wires that catch bugs!

Application builder.

Hello,
I have a program running in the LABVIEW programming mode. How can it be that
it runs without any problem, and when I want to build the same application
it with the Application builder he can't solve or find all needed vi's.
Is this magic or a bug or a joke or am I in real trouble?
Wouter.
Have program a realtime simulator for powerplants written in C++.I translates the RT sim to NI components and software (Labview).
My rt pxi turbine simulator for simulating grid incidents was succesfully used in a nuclear plant in 2006. Look at http://sine.ni.com/cs/app/doc/p/id/cs-755

> I have a program running in the LABVIEW programming mode. How can it be that
> it runs without any problem, and when I want to build the same application
> it with the Application builder he can't solve or find all needed vi's.
>
> Is this magic or a bug or a joke or am I in real trouble?
>
It probably can be solved by magic, but the spell is usually in the documentation.
If you are using a version earlier than 5.1, be sure to use File>>Save
with Options as the first step of building the application. This will
copy all of the static VIs to
one LLB, and the next step where you build the application attaches the
support code to the LLB. This is all that needs to be done for many
simple applications, but if you use dynamic VIs, it gets a little
complicated. That
is why LV.1 has a new multi-tab dialog, to handle
some of these more challenging cases.
If you have version 5.1 of LV, you probably need to upgrade for free to
5.11 and be sure to follow the steps in the Application Builder dialog.
Don't use save with options, follow the new instructions.
Greg McKaskle

Application Builder Applications List View Detail - Parsing Schema

When viewing all applications in the Application Builder using the View Detail option the list of applications is shown with the Parsing Schema showing APEX_040100 or APEX_040200 according to the apex version. Shouldn't it show the actual schema that the application will use?

Prabodh wrote:
Hi,
How will Apex know the actual schema without getting into the code and analyzing it?
I meant just showing the actual "parsing schema" which is set for the application, not all the possible schemas the application may actually reference. The parsing schema is one of the parameters asked for when importing an application. It is also defined in the application definition.
A workspace can have any number of schema assigned to it, other than the Default Parsing one. So, the only other option would be to list all the assigned schema. Which in my opinion (and most probably in the mind of the designers of Apex as well ) will be an unnecessary long list.In my opinion it seems unnecessary and fairly useless to show the APEX schema (APEX040100, APEX040200) when listing a few details of the application. Just wondering if it is on purpose or an overlooked bug.

Application builder switiches to Chinese language

I’m using LabVIEW 2010 over Windows 7 Professinal. Sometimes when building an executable all the text on the created executable standalone application changes to Chinese. After a restart of the computer and executing the application builder I get the original English text on the built executable. Does anyone have an idea on how to solve this bug?.
Thanks in advance:

Hi rotzeri,
I remember having a similar issue. I did not find a fix for it. But from memory whenever doing a build I would completely exit LabVIEW then open the project again and do the build.

4.1 Translation issue (german) in Home - Application Builder- Importieren

Hi there,
while looking a little bit around
I found a translation issue in Home -> Application Builder-> Importieren
In all cases the verb "exportieren" e.g in
"Datenbankanwendung, Seite oder Komponente exportieren"
rather must be the substantive "Export" (in fact the same as in English).
The usage of the verb is very misleading and says not what the the text is supposed to say.
(I think Patrick will see immediately what I mean.)
Also I would like to say, that the main page of APEX should be corrected
to indicate that 4.1 is running now.
Regards
Andre

Andre,
Thanks for reporting this. I'll have a bug filed on this and this will have to be fixed in APEX 4.2.
Also, thanks for pointing that out about the home page of apex.oracle.com. We have not forgotten. It will be updated when Application Express 4.1 is released.
Joel

Application builder error.llb

Hi all,
I'm using application builder to compile an executable of my VI. Compile runs without a hitch.
However, when I try to launch the .exe three subvis from error.llb are missing : Not Found Dialog.vi, Details Display Dialog.vi and Set String Value.vi
The compiled .exe seems to be looking for these VIs in instr.lib, which is nowhere to be found in the compile folder.
This happens even on my developpment machine, on which, of course, the VI runs fine from within LabView.
Did I miss something during the compiler setup ?
Thanks in advance for your help !
Nico
Solved!
Go to Solution.

I've had this before, and it was reported by NI as being a bug that comes from loading up a project that was built in an older version of LabVIEW and creating an application from it. For me it was loading a LV8.5 project into 8.6.
The only workaround was to add the three missing vi's to the project, and ensure they are added to the Always Included list within the application builder.
You will find these vi's in Program Files\National Instruments\LabVIEW 8.x\vi.lib\Utility\error.llb. Simply add them to your project somewhere, then in application builder made sure you select them as Always Included in the Source Files section, then rebuild your application.
Message Edited by Thoric on 03-13-2009 03:52 PM
Thoric (CLA, CLED, CTD and LabVIEW Champion)

Scrollbar bug in application builder

Similar Messages

Maybe you are looking for