I have some files and i use OpenDocumentFile() to open and get pFirtView of each file.
Now i have CView/CScrollView(s) for the files.
I need combine all CView/CScrollView(s) to only one CScrollView. Any suggestion? Thanks
The framework doesn't support this. You can probably hack around it by providing some sort of aggregate CView that can host multiple windows and does the layouting, but for your mental health, I suggest avoiding Doc/View for any scenario that is not exactly the way it is intended to be used, and do your window creation/drawing.
Remove the CDocTemplate based creation part in the App class, create a CWnd-derived class to host other windows and set m_pMainWnd to that window. That gets you there 90% of the way (well apart from the actual drawing in the child windows, of course...)
Related
Just like TImageList contains a collection of images, is there a similar component for generic files?
I know I can embed files as resources, but I'd like the convenience of storing different groups of files in different "TFileList" components, and to be able to retrieve files by name or by their position in the list.
Extra points if such a component allowed some sort of design time preview of the file content (just like TImageList lets you see what each image looks like, at design time).
(I come from Delphi where I wrote my own component to do the above, but before I rewrite and port the property editor and all that to Lazarus, maybe there is already something that is tried and tested...)
Thanks!
You can use pre-defined lazarus TFPGList to specialize list of the type, that you want, for example - UTF8String
But, there's no T<>List as a component, only as object.
So, yes, this feature will be useful and i can implement, if have time,
also, there's a very limited RTTI, which has been updated only a few months ago, so you can access Methods and Properties now, so FP is more systemized, than delphi pascal, but also not so enterprise-developed, which limits it to implementations for common opensource and shareware project problems.
Nevertheless, it is more stable and supported, even my friends can contribute.
I want to use Blockly to do some calculations, and then generate text files (as opposed to exporting code to JavaScript, Python, PHP, etc.)
I can’t see an obvious way to create my own blocks to do this in Blockly, so using AppInventor (Version: nb168), I got storing and retrieving files to work, in a crude test app on my Android tablet.
In AppInventor/Designer mode, clicking Storage/File creates a “Non-visible component for storing and retrieving files. Use this component to write or read files on your device.”
Then, in AppInventor/Blocks mode, clicking the “File1” icon gives access to 7 “file type blocks”, e.g. AppendToFile, Delete, ReadFrom, SaveFile, etc.
Is it possible to create similar “file type blocks” to use in Blockly Web?
I have limited programming knowledge, so would appreciate simple answers, please.
Thanks, Pete.
Andrew N Marshall from Google/Blockly has told me this:
"This is absolutely possible ...as long as you willing to work within the browser's security restrictions. The resulting files will be need to be manually "downloaded" one at a time, rather than written directly to the user's file system.
... I would start understanding what JavaScript functions are available to you. Attempt to construct a string and save it via a download dialog...
That means the "file" contents are really just a string in memory, a JavaScript variable. We have lots of "Text" blocks that can do a variety of operations on strings. If those are enough, you'll only need one new block to identify the string variable and initiate the download process.
Otherwise, you'll need to think about what blocks you want, and how they operate. They may operate on a specific variable in the JavaScript VM, not necessary exposed as a variable to Blockly.
Either way, you'll need to learn how to create a block and a Blockly app. We have a code lab that will walk you through all the steps. You'll learn how each block generates a string of code, and in your case, that code will be related to the download code I mentioned earlier."
So I'll press on - I just wanted to be sure my goal is actually achievable before I started.
Thanks, Pete.
I want to show a specified dialog under simulation category like "Developement Strategy" and do something after its "OK" click. Is there a way to show a native petrel process window?
I can see some class and interfaces in "Slb.Ocean.Petrel.UI" like DialogBuilder , DialogPage, IDialogPageFactory, IDialogPage...but I can't use them, even I don't know if they supply my required objects.
I think you want to create a Workstep (Slb.Ocean.Petrel.Workflow). The Ocean wizard lets offers a quick start. It creates optionally a process wrapper for you, which is the item showing up in the process tree.
Once you got familiar with the concepts, you can evolve the simplistic initial implementation by using the WorkflowEditorUIFactory. Check the namespace documentation in the Ocean documentation for more details.
IProcessDiagram offers different Add methods for your custom Process to enable custom positioning in the tree node sequence.
You can programmatically show a particular process dialog using DialogBuilder.ShowSettings(object) and passing the Process instance. This is typically used by a plug-in to launch its own process dialog, but it's possible to obtain a reference to the instance of a native Process by name using FindProcess(string). This is, of course, a very fragile approach:
Process p = PetrelSystem.ProcessDiagram.FindProcess("Development strategy");
PetrelSystem.DialogBuilder.ShowSettings(p);
It would need a lot of error handling, not just to guard against changes to the process name, but also to handle the case where an exclusive process dialog is already open.
However, this will still only launch the dialog. There is no way to know if/when the user clicks the OK button. Petrel processes are typically stand-alone pieces of functionality, and any kind of chaining is generally supported by creating workflows.
I have been working on cleaning an old project's resource.h.
In the project I am working on, I have some IDs which are in the form:
IDM_XXXX 32771
but are referred in code in ON_COMMAND and ON_UPDATE_COMMAND_UI statements.
So am I right in thinking that they are following the command architecture and ideally should be named as ID_XXX instead of IDM_XXXX?
I have read through TN022: Standard Commands Implementation and see that Microsoft says:
We recommend you use the standard "IDM_" prefix for menu items which
do not follow the command architecture and need menu-specific code to
enable and disable them.
I am not sure what is meant by menu-specific code here.
How are IDM_XXXX resources normally handled? Also what is the valid range range for IDM_XXXX? I have gone through TN020: ID Naming and Numbering Conventions but am confused.
ID_ and IDM_ are interchangeable because commands are accessible via command bars, menus or maybe ribbons. I never use IDM_, I only use ID_
Reserved by the MFC is 0xE000->0xEFFF and 0x7000->0x7FFF.
TN020 says that menu/command IDs must be in the range of 0x8000 and greater, but I found no reason why to do this. In the tooltip handling and command routing of the dialogs of the 16bit MFC version and AFAIK an old MFC4.x version, there was a specific code that looks for commands being greater than 0x8000.
By accident I had cases were an ID <0x8000 was created, but it worked.
I would resist not following the recommendations in the technical note. Microsoft does have undocumented messages that may interfere with your code if you violate their recommendations. And, debugging such an issue would be difficult. Additionally, following the recommendation allows you the extra benefit of...
following the MFC command architecture not only makes command handlers
more powerful (since they will work with toolbars) but makes the
command handler code reusable
This means MFC will use the same code to handle any menu and toolbar interactions that are linked together.
This may be a silly question, so forgive me if it is but I'm not a Mac guy and this is my first shot at building a serious app.
I've built a ViewController to display a tableview and data, but my app is made up of several sections which do almost the same thing. Is there a way to copy it and all the settings so I can then just go and change the minor details without having to reproduce all of the subviews and wire everything up multiple times?
Or am I just being lazy ;-)
Cheers
The proper way to do this in Cocoa is to put all your "copyable" UI/controller assemblies into their own Nib/Xib files. This way, you load a new copy of the assembly each time. See this article for the quick and dirty.
This is essentially how NSDocument works (note the separate xib for your document, separate from MainMenu.xib) and even how the prototype view of an NSCollectionView is intended to work.
Once you have your fresh copy of the assembly, you copy your settings (state) into it. "How" depends on how you have your state stored. Keep it all in a convenient place with a convenient setter/getter at the top-level object (the controller that becomes the xib's File's Owner) and you should be able to say [newController setSettings:[originalController settings]];.