Recently , I began using vbe for graphics in my OS. When in real mode, the vbe info block structure returns a pointer to the video mode list. When i view this pointer's hex value, it looks like this: It is a douleword value
0x7bb24220
I am wondering how the data at this address can be gotten in real mode , since I can't access that address. Does any one have an idea how this can be done?
This is actually not a usual pointer but a so called vbeFarPtr which has an segment:offset format. For more information see the VBE Specification (page 20).
Related
I am working on an MBCS app using MFC. I am trying to support Asian languages. For the purposes of this discussion, we'll say I'm trying to support Chinese. I am able to support Pop up dialogs via MessageBoxW and Dialog SCREENs by pasting Chinese characters directly into the RC file. I can't get file menus to work using either resource view or editing the RC file directly. Whenever I type in ANY Asian character, the screen shows ???. One ? for each character. I have tried modifying the menu in C++ using ModifyMenuW. I get more question marks. Visual Studio shows everything working, and the RC file is unicode (UTF-16). I can't easily convert my project to unicode mode. Spanish, French, and German all works fine (one of the Essets in German doesn't work, but that isn't a show stopper). What should I try next?
Thanks in advance!
Well, the easy answer would be change the application to Unicode, but this is not always simple, or possible at all.
Concerning using Unicode in a MBCS application, some things are possible and some others not. For example, I have made a MBCS application displaying and editing translations of program strings (messages, menues etc) in a ListView control, however ListView does have a specific message to turn it to Unicode (LVM_SETUNICODEFORMAT) and support operations (see also CCM_SETUNICODEFORMAT). Menus aren't controls though, but they do have "wide" (Unicode) functions.
If you want to use Unicode in your application, there are some tests you need to make. Success is not guaranteeded, but you can at least draw some conclusions and determine whether what you want to do is possible.
Test1:
You mentioned trying ModifyMenuW(), but this will try to modify an existing menu. Instead, try InsertMenuW() or InsertMenuItemW(). Any unicode string should be displayed properly, so try not just Chinese, but other laguages too (eg Greek or Russian). And btw, I can't see how French works and German doesn't (they use the same codepage - West European). What's the system codepage of your test-machine?
Test2: (if the above has failed)
Try changing the whole menu (SetMenu()) with having a single (unicode) menu item as its root.
Test3: (if the above have failed)
Then you need to check whether the window containing the menu must be Unicode. Create a simple "Hello World" Win32 application, or find a sample, if Visual Studio does not do this for you (these basically register the window class, create the main window and start the message-loop) - you must add a menu too, using the "wide" version of the menu functions explicitly. If this doesn't work, try changing the code that creates the window to unicode. This way you will know whether you need a unicode window, to own the menu.
Please make these tests and let us know the results. I will further post if needed.
When the page opens in read mode, what code is responsible in showing the "text" as opposed to "alias or saved value" of a combo box? There is some code that loops through the select items and retrieves the text of a matched value to display it in read mode. I think there is no concept of page read mode in JSF. So it must be a XPage implementation. I checked the code in renderers and the converters, still no clue. I am not trying to solve any particular issue here, just wanted to know what converter/renderer does that.
Since the behaviour is the same as it ever was using Notes client I'm sure that this is part of Domino's own data model. The special delimiter used in Notes client coding is the 'pipe' character ('|'). That is, Domino itself is serving everything left of the delimiter as 'text', and everything that's right of it as 'value'
The Microsoft Excel keyboard shortcut Ctrl+Alt+F5 to Refresh All was one of my favorites until it stopped working. Presently, when I enter that key combination nothing (as far as I can see) happens. I've had to live without it for so long that I can't recall if there was anything specific that was changed prior to it no longer working. Alt+F5 continues to work to Refresh a specific PivotTable, but that has limited value.
The version is Excel 2007.
How can I discover what is preventing Ctrl+Alt+F5 from working and restore its default functionality?
I solved this problem by disabling Intel Graphics hotkeys:
Right-click on the desktop, hover over the menu option "Graphics Options" > "Hot Keys" > click Disable.
I had the exact same issue described above, albeit on Excel 2013 then eventually worked out that the key combination Ctrl+Alt+F5 (as well as other Ctrl+Alt+Fn keys) is reserved by the Intel Graphics control panel. I'd never even noticed this program but it's accessible by right-clicking on the desktop and selecting 'Graphics Properties...'. The Intel Graphics control panel doesn't use Ctrl+Alt+F5 by default, but it still reserves it apparently. I can assure you that disabling the Intel Graphics hot keys allows me to be able to use Ctrl+Alt+F5 in Excel straight away.
Hope that helps!
By the way, this same solution is shown here for a different user problem:
https://forums.lenovo.com/t5/W-Series-ThinkPad-Laptops/hotkeys-Alt-Ctrl-F1-Alt-Ctrl-F5-which-pre-install-application/td-p/1318777
Keyposé is a free download which displays keyboard shortcuts as you use them. This makes sure that your hardware and OS are working as expected. If you see your shortcut appear with this tool (or you can verify Ctrl+Alt+F5 work in other applications another way) then the change must be within Excel itself
You might have more luck posting this on superuser.com
I've got a Visual Studio extension that I am working on. I have implemented some error tagging, which works just fine. However, some of the errors reference other locations in the code. I would like that the user can click on these locations and be taken there. The definition for ErrorTag permits an Object as the tooltip, which is not terrifically helpful, and the documentation seemed quite resistant as to what this should actually be. So far I have only been able to use a String as a tooltip.
In addition, the error popup is destroyed when the user leaves the error text span. I would need it to remain whilst the user is still on the text span or the popup content. I have discovered a PopupStyles enumeration which can control this behaviour, but I am unsure how to apply it. I would need to use the DismissOnMouseLeaveTextOrContent member to set the appropriate behaviour.
How can I implement an interactive error tooltip?
Edit: I discovered that a UIElement is a valid argument here- I replaced the String with a Label, for example. Some formatting issues aside, I still need to know how to change the popup style.
The error popup is intended to be a static tooltip and nothing more. It's not supposed to be interactive.
The PopupStyles enumeration appears to be used for the ISpaceReservationManager and IToolTipProvider -- there's no real connection to the tagging API at all. What you might be able to do is listen for the IWpfTextView.MouseHover event, and then use one of these APIs to trigger the tooltip that can be interacted with.
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.