Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. ATL / WTL / STL
  4. Modularizing Help

Modularizing Help

Scheduled Pinned Locked Moved ATL / WTL / STL
helptutorialquestiondiscussion
4 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Aaronov
    wrote on last edited by
    #1

    Hi, At my workplace we have a number of programs (sub systems) which make up our software. Some of these programs need functionality from other programs and I'm trying to find a good way to perhaps modularize each program so that common code/resources can be used "globally". The current example forcing me to find a solution is the need to launch a dialog from our Accounting package from another sub system. The big problem is that this is quite a large dialog and depends a lot on things from the Accountings MainFrame. I was thinking that for each sub system I could create a DLL which contained common dialogs, etc that could be used by other programs. The problem I face is that a lot of the dialogs have dependencies on their parent programs MainFrame and I'm not sure how to get around it. I guess one solution might be to take everything out of the MainFrame and put it into its own class which can then be passed to the DLL.. but I don't even know if that would work as I still need to Initialise this new class the same way it would be done in the parents program, but now in the other sub system.. though in saying that the DLL should probably be responsible for setting itself up. Your thoughts? Cheers

    L I 2 Replies Last reply
    0
    • A Aaronov

      Hi, At my workplace we have a number of programs (sub systems) which make up our software. Some of these programs need functionality from other programs and I'm trying to find a good way to perhaps modularize each program so that common code/resources can be used "globally". The current example forcing me to find a solution is the need to launch a dialog from our Accounting package from another sub system. The big problem is that this is quite a large dialog and depends a lot on things from the Accountings MainFrame. I was thinking that for each sub system I could create a DLL which contained common dialogs, etc that could be used by other programs. The problem I face is that a lot of the dialogs have dependencies on their parent programs MainFrame and I'm not sure how to get around it. I guess one solution might be to take everything out of the MainFrame and put it into its own class which can then be passed to the DLL.. but I don't even know if that would work as I still need to Initialise this new class the same way it would be done in the parents program, but now in the other sub system.. though in saying that the DLL should probably be responsible for setting itself up. Your thoughts? Cheers

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #2

      I do not know whether or not this has anything to do with "ATL / WTL / STL", as it seems purely a question of "Design & Architecture". I would suggest posting it in the latter forum.

      Just say 'NO' to evaluated arguments for diadic functions! Ash

      1 Reply Last reply
      0
      • A Aaronov

        Hi, At my workplace we have a number of programs (sub systems) which make up our software. Some of these programs need functionality from other programs and I'm trying to find a good way to perhaps modularize each program so that common code/resources can be used "globally". The current example forcing me to find a solution is the need to launch a dialog from our Accounting package from another sub system. The big problem is that this is quite a large dialog and depends a lot on things from the Accountings MainFrame. I was thinking that for each sub system I could create a DLL which contained common dialogs, etc that could be used by other programs. The problem I face is that a lot of the dialogs have dependencies on their parent programs MainFrame and I'm not sure how to get around it. I guess one solution might be to take everything out of the MainFrame and put it into its own class which can then be passed to the DLL.. but I don't even know if that would work as I still need to Initialise this new class the same way it would be done in the parents program, but now in the other sub system.. though in saying that the DLL should probably be responsible for setting itself up. Your thoughts? Cheers

        I Offline
        I Offline
        Intersect
        wrote on last edited by
        #3

        First of all, you have posted your question in a wrong section. Secondly, what I understood is, you need a compact solution. Lets assume you have A,B,C these three Sub programs having dependency on X,Y,Z systems. Now again you said, you have a main prog., say ProgMain, which then have a total control over A,B & C. Am I right? If this is a kind of situation, then I would rather prefer to use MFC/MDI with multi threaded arcitecture. Rather using DLL, I would suggests you to use Class files of A,B,C. I can give you better suggestion, if you can explain the situation with a good example.

        A 1 Reply Last reply
        0
        • I Intersect

          First of all, you have posted your question in a wrong section. Secondly, what I understood is, you need a compact solution. Lets assume you have A,B,C these three Sub programs having dependency on X,Y,Z systems. Now again you said, you have a main prog., say ProgMain, which then have a total control over A,B & C. Am I right? If this is a kind of situation, then I would rather prefer to use MFC/MDI with multi threaded arcitecture. Rather using DLL, I would suggests you to use Class files of A,B,C. I can give you better suggestion, if you can explain the situation with a good example.

          A Offline
          A Offline
          Aaronov
          wrote on last edited by
          #4

          I'll try explain it again as I'm not sure if your suggestion is applicable. There is a program called MainMenu which is basically the launching point for all the other sub systems like Accounting, Address Book, etc. There is now a need to be able to launch a dialog in Address Book that is in Accounting. Eg. for a person in the address book we might like to add a bank account to them so we want to the launch the "Add Account" dialog contained in the Accounting program. I can see two ways of doing this. 1. Putting common dialogs/code from each sub program into its own DLL so it can be used in other programs 2. Sending a message to main menu which then opens Accounting if its not open already, and then opens the required dialog then messages the result back. Option one I'm not entirely sure if it a good solution and option two would work but it would require a custom messaging system to be able to make it scalable I think. Are there other options out there that help with this sort of Inter-Program-Communication/Modularizing problem?

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups