I'm currently using the ShowCursor API call to hide a cursor for an application after a set period of inactivity. This works fine, except that the cursor is hidden over both the menus and status bar (which I don't want). I'm also using a Form_MouseMove to switch the cursor back on, but this doesn't work over the menus or status bar.
Is there a clever way to target hiding the cursor to just on the Form (supplying a hWnd for example, to some API call or other)?
I've tried this on my form:
With Me
.MouseIcon = LoadPicture("C:\Windows\Cursors\blank.cur")
.MousePointer = vbCustom
End With
having downloaded a blank.cur file off the internet.
The cursor disappears over the form, but is still visible over the menu bar.
Isn't there something like Form1.MousePointer = vbHourGlass property?
Yes, here.
Related
I'm working with 3d party application. Changing a text in Edit control using
SendMessageW(m_edit_handle,WM_SETTEXT,0,str_address);
And it works fine.. It changes visually in the window. But once I click a button (also programmatically) it works as there is a default value but not the one I set with SendMessageW.
Just wondering if after changing the text in Edit window I have to call some other method to force Windows to update the actual value in the field?
Depending on how the target app is coded, you may need to issue an EN_CHANGE notification to the Edit's parent window. Sending WM_SETTEXT will not send that notification, as it is meant to be sent when the user makes changes to the Edit's content, not when code does.
SendMessageW(m_edit_handle, WM_SETTEXT, 0, str_address);
SendMessageW(GetParent(m_edit_handle), WM_COMMAND, MAKEWPARAM(GetDlgCtrlID(m_edit_handle), EN_CHANGE), LPARAM(m_edit_handle));
i need to manage disable/enable Minimize,Resize and Close button by programming in oracle mdi parent forms in 10g. Please give me solution of this problems. enter image description here
There are plenty of reasons why you might want to prevent a user from being able to resize or close an application's MDI window. A perfect example would be if all the objects in the application are of a fixed size. Being able to resize the parent window would do nothing more than expose unused space. Try running Microsoft Calculator. Notice you cannot resize its window. Preventing users from not resizing certainly isn't uncommon.
So to a solution...
If you were using Forms 12.2.1+, this would be easy. In v12, Forms offers two new parameters; "isResizable" and "alwaysOnTop". Hopefully each are obvious in what they do. Simple set to TRUE or FALSE and your done.
For v11 and older, it becomes a little ugly. I will assume you are using separateFrame=true. For resizing or closing you could create a Java Bean, but that likely would be more effort than it's worth.
In PL/SQL, users attempting to close the parent window (separateFrame window) doing something like the following:
Create an Alert object and name it "PAUSE_EXIT". The alert should include two buttons (e.g. Yes/No).
Create a form level WHEN-WINDOW-CLOSED trigger and add this:
do_key('EXIT');
Create a form level KEY-EXIT trigger and add something like the following. You will have to adapt it to do the right thing in your app. You will need to account for all the "windows" in your module.
DECLARE
al_id Alert;
al_button NUMBER;
BEGIN
IF :System.Event_Window = 'FORMS_MDI_WINDOW' THEN
al_button := Show_Alert('PAUSE_EXIT');
IF al_button = ALERT_BUTTON1 THEN
-- User selected YES, so exit.
EXIT_FORM;
ELSE
-- User selected NO, so don't exit.
RAISE Form_Trigger_Failure;
END IF;
ELSE
-- User attempted to close a form window and not the MDI window
-- Remove NULL and do something else if not the MDI window
NULL;
END IF;
END;
A similar approach could be used to detect if the MDI window has been minimized or resized. Look in the Builder Help for these: SYSTEM.EVENT_WINDOW, GET_WINDOW_STATE, WHEN-WINDOW-RESIZE
To prevent users from clicking in my main_window when a MessageBox appears I have used:
EnableWindow(main_window,FALSE);
I got a sample MessageBox:
EnableWindow(main_window,FALSE);
MessageBox(NULL,"some text here","About me",MB_ICONASTERISK);
EnableWindow(main_window,TRUE);
The problem is that when I press "OK" on my MessageBox it closes and my main_window is send to back of all other system windows. Why this is happening?
I tried to put:
SetFocus(main_window);
SetActiveWindow(main_window);
after and before : EnableWindow(main_window,TRUE) the result was strange: it worked 50/50. Guess I do it the way it shouldn't be.
Btw.
Is there a better solution to BLOCK mouse click's on specific window than:
EnableWindow(main_window,FALSE);
Displaying modal UI requires that the modal child is enabled and the owner is disabled. When the modal child is finished the procedure has to be reversed. The code you posted looks like a straight forward way to implement this.
Except, it isn't.
The problem is in between the calls to MessageBox and EnableWindow, code that you did not write. MessageBox returns after the modal child (the message box) has been destroyed. Since this is the window with foreground activiation the window manager then tries to find a new window to activate. There is no owning window, so it starts searching from the top of the Z-order. The first window it finds is yours, but it is still disabled. So the window manager skips it and looks for another window, one that is not disabled. By the time the call to EnableWindow is executed it is too late - the window manager has already concluded that another window should be activated.
The correct order would be to enable the owner prior to destroying the modal UI.
This, however, is only necessary if you have a reason to implement modality yourself. The system provides a standard implementation for modal UI. To make use of it pass a handle to the owning window to calls like MessageBox or CreateDialog (*), and the window manager will do all the heavy lifting for you.
(*): The formal parameter to CreateDialog is unfortunately misnamed as hWndParent. Parent-child and owner-owned relationships are very different (see About Windows).
I wan't to have a simple menu (main menu not menu bar) whith buttons to link to another form(s)/window(s)/caveses(s). Or atleast the code to switch bettween the screen.
What code (SQL/PL) would I put in the buttons or is there a better way to do this?
That's a very broad question. If you want to show a specific window on WHEN-BUTTON-PRESSED then you can use built in like below-
SET_WINDOW_PROPERTY('WINDOW_NAME', VISIBLE, PROPERTY_TRUE); --This would display the window
SET_WINDOW_PROPERTY('WINDOW_NAME', VISIBLE, PROPERTY_FALSE); --This will hide the window
The above would work if you use the SET_WINDOW_PROPERTY within the same form.
In case you want to call another form from the parent form (which is the case as per your comment screenshot) you need to to use CALL_FORM built-in like
CALL_FORM('MEMBERS');
Why dont you just make 1 form only?1 form, many datablock,canvas, window
anyway, for your question, just call the block
go_block('your_block');
if you want to call another block
go_block('another_block');
hide_window('1st_open_window');
you should make 1 canvas in 1 window for better arrangement
You can also use Stack canvas within the same form which gets visible as you click on the button.
SHOW_VIEW('CANVAS_NAME');
And in that stack you can do whatever you want.
We have a VB6 application that uses a non-visible window (form) for DDE communication.
We have some clients reporting that occasionally they can see this window on their desktop.
I did a scan through the code for any visible = true or show's on the form in question, but nothing.
This about all we do with it:
Load frmDDELink
frmDDELink.stuff = stuff
We don't actually explicitly display (or explicitly not display it either).
What could cause a hidden window to be displayed on a user's desktop such that it is visible?
Try and set the location of the form to off-screen.
frmDDELink.ClientLeft = -100
frmDDELink.ClientTop = -100
A misbehaving app on the client's machine could do that. FindWindow() is a notoriously inaccurate API function. On top of that, all VB6 windows have the same class name. Thunder something, iirc. It might be finding your window instead of the one intended, making the wrong window visible.
I like Black Frog's simple hint to set the location off-screen, and nobugz's possible explanation. I would also suggest handling the Form_Activate event and setting the form invisible again.
Private Sub Form_Activate()
'Log something for debugging purposes?'
Me.Visible = False
End Sub
try to set the border into none, or me.visible = false, and set the property not to display in the task bar.