Set_window_property locked to maximize

set_window_property('WINDOW1',window_state,maximize);
how is it possible to lock it on maximize so the user wont be able to change it?
thanks

As noted by Francois, you will need to use a java bean.
See my comments here:
Why my main window executing oracle forms cant' be in full screen ?

Similar Messages

SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE); and Forms9i

Hi All,
I have this problem, whenever I try to resize the MDI window to its maximum state for a form to run on the web, the forms doesn't seem to take any action , means the statement SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE); won't be executed by Oracle Forms 9i or 10g , does any one have a clue or faced this kind of problem before, please reply if you have anyway to sort this problem out.
Regards,
Islam

thanks for your reply,
no it's running on separate frame(window), but im running the application from the iAS, so is there any .cfg file for the forms server installed on the iAS that has to be configured , as when I run the application, it runs on separate frame (window) , so I assume it's set to SeperateFrame=True for the forms server as well.

MAXIMIZE WINDOW DOES NOT WORK IN FORMS 9i

Hi,
I am performing forms conversion and developing new forms in Forms 9i. The problem I am running into is that :
the SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE)
and SET_WINDOW_PROPERTY(ROOT_WINDOW, WINDOW_STATE, MAXIMIZE)
in the When_new_form_instance trigger don't work.
I've also tried adding a parameter to initiate the running mode as WEB as suggested in a response that I saw on this
forum, with that parameter I would set the ROOT_WINDOW State to NORMAL
then set WIDHT=800, HEIGHT=600, POSITION=0, 24.........
but it still does not work. When I run the form, the browser opens up as a full screen, but the form only fills up the gray rectangular
area when the Jiniator is running and loading the applet.
If I don't set the Maximize property of the main window to Yes then the vertical and horizontal scroll bars are automatically added,
if I do set so then no scroll bar is added and the form is cut off.
Is it a known problem ? and is there a solution to it?
Any response is greatly appreciated.
Thanks.
TLe

Thanks, it worked, and I've been playing with other parameters, such as replacing the lookandfeel (this works), but splashscreen and background don't when I specified the .GIF file name, it did not display the GIF image.
Thanks again.

Set_window_property('forms_mdi_window',window_state,minimize) not working

Hi all,
set_window_property('forms_mdi_window',window_state,maximize)
is working but
set_window_property('forms_mdi_window',window_state,minimize)
not working!
mdi window is not displayed.
when i am typing minimize it turns into blue which should not like that. that means the syntax has mistake am i right,if u type maximize it is not turning into blue and works fine
any help pls
asp

Hi all
Still i am strugglling, i am working on this small problem for hours and hours, i created many complex forms but still i am breaking my head with this problem.
set_window_property(forms_mdi_window,window_state,maximize);
working fine.
when you type the above syntax in maximize in syntax, it is not turning to blue. but if u specify the minimize it is turning into blue(some body told its reserve word)
in my if i say maximize my form is displaying , its cool,
if i specify minmize ...oooopppps my mdi window ifself not displyed in the browser, only i am able to see the default menu bar !
What happened, i am working on this problem for hours and hours
FORMS EXPERTS UR ATTENTION PLEASE.
Is there is any problem with my formweb.cfg file
any help ?
thanx
asp

How to maximize the java applet?

Dear all,
I have an application & when ever i run it, the java applet never comes in a maximum size. so is there a way to make it run in a maximum size?
best regards,
Ashraf

so but htese two lines in the new_form_instancse trigger
SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW,WINDOW_STATE,MAXIMIZE);
SET_WINDOW_PROPERTY('WINDOW1',WINDOW_STATE,MAXIMIZE);
good luck

Maximize window in oracle forms

Hi,
I want to maximize the window (auto fit) in oracle forms 11g.
In pre-form I use
SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE);
Still not working.
I want my main form should be fit in browser.
Please help...
Thanks in advance.
Edited by: parapr on Aug 24, 2012 9:18 PM

I am using content canvas and tab canvas in same screen.Now I am able to view all the field but i need to scroll down below to see all the fields, I want all the fields should be displayed without scroll down.>
The screen is your real estate. If you have a 1000 sq ft of plot and want to fit a building with 2000 sq ft floorspace on it how would you do it?
a. Reduce the plan area by making fewer rooms or smaller rooms?(reduce field sizes, make multiple blocks , increase min required resolution )
b. Make a multi storey building (stacked canvas ? multi-block?)
The same logic applies to forms.
Cheers,

Set window property maximize

hi everybody
i create a form
and set window size maximize i.e.
set_window_property(MDI,window_state,maximize)
it show window maximize in screen area(800,600)
but when i set screen resulation(1024,768)
then it show at halp screen(as not fit in screen)
is any solution that in (1024,786) resulation it show
in all screen
with thanx

yes. you are using the right code. It should work. If it doesn't, it means that somewhere in your application the mdi-window size is set differently.
you can verify this by calling show_alert right after your code:
set_window_property( forms_mdi_window, window_state, maximize );
set_alert_property( '<alert_name>', alert_message_text, 'window-state is now: ' || get_window_property( forms_mdi_window, window_state ) );
l_button := show_alert( '<alert_name>' );
Good Luck!

How do I maximize the window on startup?

I have a when-new-form-instance trigger that calls set_window_property('WINDOW1',WINDOW_STATE,MAXIMIZE) but it does not maximize my window. I am running my form in a separate window . I am running forms10.1.2.0.2 with Oracle express 10g. My formsweb.cfg looks like this:
[myapp]
userid=myuser/mypass@xe
form=myform.fmx
width=750
height=700
splashScreen=NO
colorScheme=Titanium
separateFrame=True
Also, the above works except splashScreen=NO. I am still getting "ORACLE FORMS." on the screen before my form is displayed. Before I set splashScreen to NO, I was getting the Oracle Forms startup splashscreen. So it looks like it took one splashScreen away and gave me a default. I tried configuring so that my own splashScreen (gif file) would be called, but that didn't work either. I must've done something wrong. How do I configure to use my own gif file as a splashScreen? Another question I have relating to running forms with the above configuration: Whenever I close the form, I need to also close the browser. How can I programmatically close the browser window too?

The I figured out to use BACKGROUND parameter to get the gif file to display, but it's coming out as a black square. Is it a problem with my gif file? (I can open it in other tools & it looks OK)

Need details about "Lock Profiling" tab of JRockit JRA

Hi,
I'm experimenting with the JRockit JRA tool: I think this is a very useful tool ! It provides very valuable information.
About locks ("Lock Profiling" tab), since JRockit manages locks in a very sophisticated manneer, it enables to get very important information about which monitors are used by the application, helping for improving the performances.
Nevertheless, the BEA categories (thin/fat, uncontended/contended, recursive, after sleep) are not so clear. A short paper explaining what they mean would greatly help.
Fat contended monitors cost the most, but maybe 10000 thin uncontended locks cost the same as 1 fat contended lock does. We don't know.
So, there is a lack of information about the cost (absolute: in ms, or relative: 1 fat lock costs as N thin locks) of each kind of monitor. This information would dramaticaly help people searching where improvements of lock management are required in their application.
Thanks,
Tony

great explanation! Thanks
"ihse" <[email protected]> wrote in message
news:18555807.1105611467160.JavaMail.root@jserv5...
About thin, fat, recursive and contended locks in JRockit:
Let's start with the easiest part: recursive locks. A recursive lock
occurs in the following scenario:synchronized(foo) { // first time thread takes lock
synchronized(foo) { // this time, the lock is taken recursively
}The recursive lock taking may also occur in a method call several levels
down - it doesn't matter. Recursive locks are not neccessarily any sign of
bad programming, at least not if the recursive lock taking is done by a
separate method.
The good news is that recursive lock taking in JRockit is extremely fast.
In fact, the cost to take a lock recursively is almost negligable. This is
regardless if the lock was originally taken as a thin or a fat lock
(explained in detail below).
Now let's talk a bit about contention. Contention occurs whenever a thread
tries to take a lock, and that lock is not available (that is, it is held
by another thread). Let me be clear: contention ALWAYS costs in terms of
performance. The exact cost depends on many factors. I'll get to some more
details on the costs later on.
So if performance is an issue, you should strive to avoid contention.
Unfortunately, in many cases it is not possible to avoid contention -- if
you're application requires several threads to access a single, shared
resource at the same time, contention is unavoidable. Some designs are
better than others, though. Be careful that you don't overuse
synchronized-blocks. Minimize the code that has to be run while holding a
highly-contended lock. Don't use a single lock to protect unrelated
resources, if that lock proves to be easily contended.
In principle, that is all you can do as an application developer: design
your program to avoid contention, if possible. There are some experimental
flags to change some of the JRockit locking behaviour, but I strongly
discourage anyone from using these. The default values is carefully
trimmed, and changing this is likely to result in worse, rather than
better, performance.
Still, I understand if you're curious to what JRockit is doing with your
application. I'll give some more details about the locking strategies in
JRockit.
All objects in Java are potential locks (monitors). This potential is
realized as an actual lock as soon as any thread enters a synchronized
block on that object. When a lock is "born" in this way, it is a kind of
lock that is known as a "thin lock". A thin lock has the following
characteristics:
* It requires no extra memory -- all information about the lock is stored
in the object itself.
* It is fast to take.
* Other threads that try to take the lock cannot register themselves as
contending.
The most costly part of taking a thin lock is a CAS (compare-and-swap)
operation. It's an atomic instruction, which means as far as CPU
instructions goes, it is dead slow. Compared to other parts of locking
(contention in general, and taking fat locks in specific), it is still
very fast.
For locks that are mostly uncontended, thin locks are great. There is
little overhead compared to no locking, which is good since a lot of Java
code (especially in the class library) use lot of synchronization.
However, as soon as a lock becomes contended, the situation is not longer
as obvious as to what is most efficient. If a lock is held for just a very
short moment of time, and JRockit is running on a multi-CPU (SMP) machine,
the best strategy is to "spin-lock". This means, that the thread that
wants the lock continuously checks if the lock is still taken, "spinning"
in a tight loop. This of course means some performance loss: no actual
user code is running, and the CPU is "wasting" time that could have been
spent on other threads. Still, if the lock is released by the other
threads after just a few cycles in the spin loop, this method is
preferable. This is what's meant by a "contended thin lock".
If the lock is not going to be released very fast, using this method on
contention would lead to bad performance. In that case, the lock is
"inflated" to a "fat lock". A fat lock has the following characteristics:
* It requeries a little extra memory, in terms of a separate list of
threads wanting to acquire the lock.
* It is relatively slow to take.
* One (or more) threads can register as queueing for (blocking on) that
lock.
A thread that encounters contention on a fat lock register itself as
blocking on that lock, and goes to sleep. This means giving up the rest of
its time quantum given to it by the OS. While this means that the CPU will
be used for running real user code on another thread, the extra context
switch is still expensive, compared to spin locking. When a thread does
this, we have a "contended fat lock".
When the last contending thread releases a fat lock, the lock normally
remains fat. Taking a fat lock, even without contention, is more expensive
than taking a fat lock (but less expensive than converting a thin lock to
a fat lock). If JRockit believes that the lock would benefit from being
thin (basically, if the contention was pure "bad luck" and the lock
normally is uncontended), it might "deflate" it to a thin lock again.
A special note regarding locks: if wait/notify/notifyAll is called on a
lock, it will automatically inflate to a fat lock. A good advice (not only
for this reason) is therefore not to mix "actual" locking with this kind
of notification on a single object.
JRockit uses a complex set of heuristics to determine amongst other
things:
* When to spin-lock on a thin lock (and how long), and when to inflate it
to a fat lock on contention.
* If and when to deflate a fat lock back to a thin lock.
* If and when to skip on the fairness on a contended fat lock to improve
performance.
These heuristics are dynamically adaptive, which means that they will
automatically change to what's best suited for the actual application that
is being run.
Since the switch beteen thin and fat locks are done automatically by
JRockit to the kind of lock that maximizes performance of the application,
the relative difference in performance between thin and fat locks
shouldn't really be of any concern to the user. It is impossible to give a
general answer to this question anyhow, since it differs from system to
system, depending on how many CPU:s you have, what kind of CPU:s, the
performance on other parts of the system (memory, cache, etc) and similar
factors. In addition to this, it is also very hard to give a good answer
to the question even for a specific system. Especially tricky is it to
determine with any accuracy the time spent spinning on contended thin
locks, since JRockit loops just a few machine instuctions a few times
before giving up, and profiling of this is likely to heavily influence the
time, giving a skewed image of the performance.
To summarize:
If you're concerned about performance, and can change your program to
avoid contention on a lock - then do so. If you can't avoid contention,
try to keep the code needed to run contended to a minimum. JRockit will
then do whatever is in its power to run your progam as fast as possible.
Use the lock information provided by JRA as a hint: fat locks are likely
to have been contended much or for a long time. Put your effort on
minimizing contention on them.

9i forms_mdi_window maximize doesn't truly maximize Applett window

When I start a 9i Form it pops up in a separate Applett window, and then the form does a:
set_window_property(FORMS_MDI_WINDOW,WINDOW_STATE, MAXIMIZE);
However, this does not exactly maximize the Applett window. It just makes it as big as the whole desktop, which incidentally extends the status bar below the Task Bar/Start Menu on the MS Windows desktop.
Manually pressing the maximize button on the MDI windows is, however, able to do a maximize. However, setting it programmatically does not work the same as under 6i (which did it correctly).
Is there a way to actually make it maximize the MDI window programmatically?
Sincerely,
Jesper Vad Kristensen
Aarhus, Denmark.

I think I have a slightly different problem
I can still see the staus bar and message bar and the browser window does not obsure the windows task bar.
The forms window within the java applet does not maximise as it used to in 6i client server.
Previously the minimise/restore/close buttons were directly under the main runtime window (is that the MDI window?)
Now there is an extra window bar underneath the menu and toolbar canvas. It is maximised but doesn't integrate itself into the MDI window as previously.

Maximize the applet window

Hi all. I'm on devsuite 10g. I'm running my form with separateframe=true. I would know if there is something that I can do to maximize the applet window, in which there is my form.
In the formweb.cfg file I have modified the parameters as follow:
width=100%
height=100%
but the window in which there is the form (probably the applet window) is not maximized.
Here is the code of my when-window-activated trigger:
Set_Window_Property(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE);
Set_Window_Property('WINDOW1', WINDOW_STATE, MAXIMIZE);
Set_Window_Property('WINDOW2', WINDOW_STATE, MAXIMIZE);
Set_Window_Property('WINDOW3', WINDOW_STATE, MAXIMIZE);
So what can I do???
Thanks all for the collaboration,
Fabrizio

try making width=100%
height=100% in formsweb.cfg
also search this forum for some answers

Form 9i Maximize/Minimize

Hi,
I am trying to Maximize a form using SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE) and SET_WINDOW_PROPERTY('WINDOW1',WINDOW_STATE, MAXIMIZE). I found it work with 6i, but it is not working with 9i forms. Could any body please help me in this regards?
Sarwar
email: [email protected]

Hi,
Please post this question in Oracle Forms Forum.
Here is the url:
Forms
Siva

Set_window_property

hi friends
when i run the form the full form is not shown some of the the explorer area free
i want when i run the form it will fit to window
thnks in advance
regards

Try this code:
You must put it in WHEN-NEW-FORM-INSTANCE trigger and in WHEN-WINDOW-ACTIVATED trigger at form level
 SET_WINDOW_PROPERTY ('YOUR_WINDOW_NAME',WINDOW_STATE,MAXIMIZE); SET_WINDOW_PROPERTY (FORMS_MDI_WINDOW,WINDOW_STATE,MAXIMIZE); Hope it helps you,
Fabrizio
If this answer is helpful or correct, please mark it. Thanks.
Edited by: Fabrizio Delli Priscoli on 22-ott-2008 9.39

Work-around to maximize a window

Hi
I am using the following code to maximize my windows
SET_WINDOW_PROPERTY(FORMS_MDI_WINDOW, WINDOW_STATE, MAXIMIZE);
SET_WINDOW_PROPERTY('TOP_WINDOW',WINDOW_STATE, MAXIMIZE);however when I run the form via application server, the user still needs to double click the master window title bar to see the default oracle's message bar to see the running count e.g. Record: 1 / ? at the bottom.
if this is an issue with my current version of forms which is Forms [32 Bit] Version 10.1.2.3.0 (Production), is there a way to replicate the oracle message bar so that it is viewable?

Hello,
This is the default Applet behavior. This maximize property won't work for the web base forms.
In the alternative solution what you can do is you can resize the page length from the Application Server configuration. Decrease the length from configuration then it can fit completely in front of user.
-Ammad

Window maximize in 10g

Hi!
how can we maximize mdi window in 10g?
i am using separateframe = true.
using when-new-form-instance to maximize and set title of mdi window. this trigger set the title of mdi window but it fills screen , do not maximize mdi window.
thanx

This has to do with bug nr. 2696694
Hello,
This problem is described in bug:2696694 - FORMS MDI WINDOW MAXIMIZE NOT WORKING PROPERLY USING SET_WINDOW_PROPERTY.
This bug has a base bug.
"If you use the maximize icon at the top right hand corner of the MDI frame it does seem to
size the window correctly, taking into account the startbar at the bottom on win2k. However when we initially maximize it by calling set_window_property(forms
_mdi_window,window_state,maximize)it doesn't take into account the startbar. In
fact it doesn't appear to be maximized according to the state of the 'maximize'
icon. "
So "Forms is not using this capability when calling set_window_property(forms_mdi_window,window_state,maximize).""
I tried to set window height and width using Set_Window_Property, but the result was the same.
So I'm afraid all you can do is to use the workaround suggested in the 1st bug, i.e.:
".. click the little window, the icon changes to "two overlapping little windows" and the desi
red effect is given which shows both the windows task bar "
I know that this is not a good suggestion, but that's all I can suggest.
According to the text om metalink refering to the bug (2696694), the bug awaits resolution.
Is there another JVM/ another Jinitiator version available that will let the applet window maximize. Sofar I wasn't able to find a good work around.
Thanks in advance for yous suggestions.
Regards,
Thomas

Set_window_property locked to maximize

Similar Messages

Maybe you are looking for